IRC logs for #openttd on OFTC at 2024-01-21
ā“ go to previous day
00:30:00 <peter1138[d]> Yeah... that needs a bit more thought on when to update the lists š
01:11:23 *** bryjen has quit IRC (Quit: Leaving)
02:52:13 *** Tirili has quit IRC (Quit: Leaving)
03:39:41 *** debdog has quit IRC (Ping timeout: 480 seconds)
06:02:43 *** bigyihsuan has joined #openttd
06:02:43 <bigyihsuan> when did this option get introduced (and is this a jgrpp option)?
06:07:00 <bigyihsuan> ah i see what this option's for, 27 ms/tick * 74 tick/day = 1998 ms/day, or about 2 seconds
07:32:10 *** tokai|noir has joined #openttd
07:32:11 *** ChanServ sets mode: +v tokai|noir
07:38:56 *** tokai has quit IRC (Ping timeout: 480 seconds)
08:10:30 *** bryjen has quit IRC (Quit: Leaving)
08:24:05 *** nanapipirara has joined #openttd
08:24:05 <nanapipirara> Just a thought about transparency and I've got no idea what the implications are, but I've always felt the transparent trees are still visually too crowded (and thus I usually turn them completely invisible, which is a shame). But if the transparent pixels of hidden trees wouldn't stack it would look a lot less busy (which is the point of setting them to transparent)
08:25:07 <nanapipirara> Here's a mockup (in a different style, but it would make even more sense with the original trees, because they have more detail, thus more noise)
08:26:45 <nanapipirara> (middle is current behaviour, right picture is mockup)
08:37:33 *** belajalilija has joined #openttd
08:37:33 <belajalilija> honestly a nice QoL idea
09:00:46 <_zephyris> Nice thought. The same could apply to all types of transparency... But I believe next to impossible.
09:02:22 <_zephyris> Because of cases like a tree partly occluded by a building.
09:06:14 <_zephyris> Hmm, could be done by drawing without trees, drawing a parallel buffer with trees recoloured white, everything else recoloured black, then take that channel as the basis of the alpha for the transparency overlay. Huge amount of work.
09:11:02 <peter1138[d]> Very much TMWFTLB
09:34:20 <peter1138[d]> Hmm, -Og with clang is too much for debug.
09:35:28 <peter1138[d]> > -Og Like -O1. In future versions, this option might disable different optimizations in order to improve debuggability.
09:36:50 <peter1138[d]> Hmm, I guess 128000 byte static array is not so bad.
09:39:13 <truebrain> depends for what, ofc š
09:39:31 <peter1138[d]> Count of each object type in the game.
09:39:40 <peter1138[d]> It is a bit frivolous.
09:40:49 <peter1138[d]> It could be a vector sized to the actual number of objects, instead of NUM_OBJECTS.
09:41:00 <peter1138[d]> Or stored in ObjectSpec.
09:41:42 <truebrain> peter1138[d]: You can do `-O2` with a high enough `-g` level. `-ggdb` on GCC is pretty nice .. `-g3` if you want to know about macros. It still optimizes them away, but a good debugger can deduce back where abouts the code came from
09:42:11 <truebrain> then again, it is not like we spend a great amount of time in debuggers with OpenTTD. At least, 1 out of the .. 100? times I have a crash I want to analyse. Most of the time I know where the crash comes from, during development š
09:45:22 <peter1138[d]> I guess I spend more time with my own buggy code š
09:45:43 <peter1138[d]> And switching from RelWithDebInfo to Debug takes AAGGGESSS š
09:45:51 <truebrain> I have to admit, I am a printf debugger š
09:46:05 <truebrain> but maybe try for a while or so to add -O2 in debug builds, with -ggdb
09:46:10 <truebrain> see if you notice any problems while working
09:46:24 <truebrain> or -g2 (which is the default on GCC; don't know about clang)
09:49:51 <peter1138[d]> I do lots of fmt::println debugging too š
09:50:12 <truebrain> I had colleagues which were very .. euh .. weirded out by the fact I do
09:50:22 <truebrain> when they had an issue, they start to open debuggers, and do this and that and that and that
09:50:29 <truebrain> I am just like .. or you add a single printf here?
09:50:33 <truebrain> I dunno ... from another generation
09:50:42 <peter1138[d]> printf is very useful for tracking state over time.
09:51:02 <peter1138[d]> It's basically a debug message which is not going to stay š
09:51:41 <truebrain> sometimes I forget to remove them š
10:02:11 <truebrain> Rubidium: to help out with reviewing of that PR, I split it up in much smaller commits; hopefully that helps in finding mistakes š
10:06:43 <truebrain> right, now to port my changes of discord-social to the other plugins .. this is going to be though š¦
10:08:16 *** HerzogDeXtEr1 has joined #openttd
10:13:06 *** HerzogDeXtEr has quit IRC (Ping timeout: 480 seconds)
10:16:09 <truebrain> let's see if I did this correct first try
10:19:27 <xarick> wow, 10544 only compiles on windows, fails on every other
10:19:42 <locosage> I think I switched to print debugging completely with python. It's so much better when you can just print anything. But I've used it quite often even before that.
10:20:41 <andythenorth> I never learnt to use a debugger
10:21:17 <andythenorth> I wrote my own for Flash games where you could type in a var name (scoped by object if needed) to a field on the screen in the game š
10:21:41 <andythenorth> 'print' is just easier, unless you're a proper programmer
10:21:55 <locosage> I never quite learned linux debuggers before switching from windows I used VS debugger a lot
10:22:04 <andythenorth> the thing I find when I've worked with proper programmers: they often don't ship much stuff
10:22:14 <andythenorth> everything is done properly, but not actually done
10:22:45 <locosage> I literally have to read manual pretty much every time I fire up gdb xD
10:23:23 <truebrain> I am still incapable of making changes right the first time .. lol .. so much noise of me failing š
10:23:39 <andythenorth> I type one line of code then compile
10:23:46 <andythenorth> that's why compile time is so important š
10:24:57 <xarick> an error that spawns from line 650 to 831... on a compiler I don't even care about
10:25:05 <xarick> how do you even deal with this
10:25:49 <locosage> lol, it was nearly impossible for me to do anything openttd with old laptop. by the time 5 min compile is done I already forget I did something xD
10:26:21 <xarick> error: no matching function for call to 'find'
10:26:38 <xarick> if (std::find(tile_dists.begin(), tile_dists.end(), std::pair(current_aqueduct_tile, dist)) == tile_dists.end()) {
10:27:38 <andythenorth> woah, we did what now in vanilla? š®
10:27:39 <xarick> I don't even know how to verify this
10:27:40 <andythenorth> who did this and when
10:27:46 <peter1138[d]> `std::make_pair`
10:27:49 <andythenorth> please send them cookies
10:28:30 <locosage> clean compile of bonkygfx is 7.5 sec, it's already getting me concerned
10:28:49 <locosage> a lot of it is just running aseprite exports though
10:28:53 <xarick> std::make_pair will work?
10:29:23 <xarick> but... I'm not exactly making a new pair
10:29:43 <peter1138[d]> But std::pair() is pretty odd.
10:31:04 <xarick> ok let's try, see what it will complain about next
10:31:46 <locosage> hm, I wonder if there is a faster way to run same executable on different args
10:31:49 <locosage> like fork it or smth
10:31:57 <locosage> I guess os should do that somehow
10:32:14 <peter1138[d]> Your `for (const std::pair tile` should be `for (const auto &tile`
10:34:21 <xarick> funny that it didn't error on line 504
10:34:26 <xarick> it does the same thing
10:35:40 <truebrain> lol .. "why do my checksum not match?!" .. I was doing the signature of the non-stripped library, and then stripping it, being surprised the checksum is invalid
10:35:45 <truebrain> doing this stuff in CMake is hard
10:37:36 <xarick> something else is going on
10:38:22 <truebrain> lol, and now it works with "make install", but not with "cpack", as cpack does things slightly different š Owh CMake .... you are joyful and the worst all at the same time š
10:41:33 <xarick> do I leave line 504 with std::pair and line 528 with std::make_pair?
10:43:31 <truebrain> anyone here that knows a thing or two about running a job during CMake "install" ?
10:43:51 <truebrain> I can't find a way to execute a small script just after install is finished
10:46:42 <xarick> okay let's see what happens
10:55:06 <peter1138[d]> Hmm, storing object count with object spec feels wrong š®
10:56:38 <truebrain> okay, so there are post-build script hooks, but only when you do `cpack` .. and not when you do `make install` (which you do during development)
10:57:01 <truebrain> but you can't figure out the cpack folder `cpack` is using in a post-install hook
10:57:04 <truebrain> this is so weird š
10:58:21 <peter1138[d]> I've... never used make install
10:58:46 <truebrain> for plugins you kinda want to
10:58:53 <truebrain> as they need to be moved to the OpenTTD social_integration folder
10:59:01 <truebrain> and manually copying them is .. a recipe for disaster
10:59:09 <truebrain> "why doesn't it change anything?! Owh .. forgot to copy again" š
10:59:20 <truebrain> so setting a custom install-folder and running `make install` solves that š
11:06:04 <peter1138[d]> Crap, I forgot to disable SDL2 again when switching Kit :/
11:06:18 <truebrain> 2 build-folders? š
11:09:25 <truebrain> `the following variables will be set: CMAKE_CURRENT_SOURCE_DIR, CMAKE_CURRENT_BINARY_DIR and CMAKE_INSTALL_PREFIX (which is set to the staging install directory)`
11:09:28 <truebrain> turns out, that is a lie
11:09:35 <truebrain> `CMAKE_INSTALL_PREFIX` is not set to the staging folder
11:16:10 <peter1138[d]> Can we get rid of hpp vs h? There's no need for it :/
11:16:50 <peter1138[d]> 586 .h, 177 .hpp.
11:23:05 <xarick> erm... it keeps failing
11:27:06 <truebrain> finally I have something working for Linux ... now let's hope it also works on the other OSes š
11:28:53 <truebrain> oops, wrong branch; owh well
11:29:10 <truebrain> didn't mean to spam this channel with my tests š
11:29:20 <peter1138[d]> Everyone else does.
11:29:39 <truebrain> Doesn't mean I have to join that "everyone" š
11:30:06 <truebrain> how am I suppose to review 11852 ...
11:31:05 <truebrain> not, was the answer
11:32:55 <truebrain> oops, I made a big boo-boo .... I am assuming libraries always end with *.so .. that is a lie ofc š
11:36:13 <xarick> i can't make this work
11:36:45 <xarick> ` auto tile_dist = std::make_pair(current_edge_tile, 0);
11:36:45 <xarick> if (std::find(tile_dists.begin(), tile_dists.end(), tile_dist) == tile_dists.end()) {
11:36:45 <xarick> tile_dists.push_back(tile_dist);
11:36:53 <xarick> it compiles only on windows
11:39:15 <_jgr_> You likely need to specify the actual template parameters you want in your call to make_pair
11:39:22 <_jgr_> Or just use a normal struct instead?
11:45:34 <peter1138[d]> `std::make_pair<firsttype, secondtype>(..., ...)`
11:48:09 <xarick> ah, I see, makes sense
11:50:12 <truebrain> Grrr, all but MacOS work .. how am I going to debug that š
12:08:44 <_glx_> xarick: Use `auto` for the variable type
12:17:43 <xarick> this works auto tile_dist = std::pair<const TileIndex, int>(current_aqueduct_tile, dist);
12:17:55 <xarick> but will it work on the other compilers?
12:29:22 <xarick> woah, it's passing linuxes's
12:30:51 <xarick> I guess I could just push back unconditionally
12:31:44 <xarick> there's my fear that aqueducts at the edge might conflict with edge tiles at the edge
12:31:56 <xarick> so I was preventing duplicates
12:35:59 <truebrain> will it work will it work will it work, that is the quueeesssttttiiiiiooooonnnnnnnn
12:41:24 <truebrain> okay, MacOS also made a signature file \o/
12:41:59 <peter1138[d]> Hmm, okay, so object::colour is actually 2 colours.
12:42:19 <truebrain> and the signatures on Linux are valid \o/
12:43:28 <truebrain> and on MacOS and Windows they are also correct
12:43:32 <truebrain> finally .. something that works š
12:45:10 <peter1138[d]> Hmm, should I split Object::colour into Object::colour1/colour2?
12:45:19 <peter1138[d]> Would require a savegame bump.
12:45:32 <truebrain> what are the benefits?
12:45:35 <peter1138[d]> And Colours is only 4 bits currently.
12:45:46 <peter1138[d]> Nothing really yet.
12:46:06 <peter1138[d]> I have a PR to store Colours in a Colours type instead of byte. But this one is differen.t
12:46:08 <truebrain> peter1138[d]: You make it sound like that is expensive š
12:46:11 <peter1138[d]> Might just ignore it for now š
12:46:59 <peter1138[d]> Nah, not expensive, just storing both in one byte means I can't treat it as Colours directly š
12:47:23 <truebrain> yeah .. bit-shifting isn't actually needed anymore š
12:47:44 <truebrain> well, for Map it is still, but details detail š
12:48:52 <truebrain> okay, Discord also seems to work ... now to do the same for GOG
12:52:27 <peter1138[d]> "Reduces casts" "Removes 14, adds 6" š®
12:58:38 <truebrain> hopefully this is finally it ..
12:59:19 <truebrain> plugins are now signed by an OpenTTD key, and we only allow loading plugins if they are signed by our key. This means nobody but us can sign off on plugins. Meaning there is not a higher than normal risk that a coinminer is distributed š
13:00:35 <truebrain> many things can be added and improved .. but for a first version, I am pretty happy with this š
13:06:56 <truebrain> w00p, GOG Galaxy also loads fine now. Nice š
13:11:33 <xarick> All checks have passed
13:11:33 <xarick> 1 skipped and 19 successful checks
13:12:36 <truebrain> emperorjake: up for testing social integration on MacOS one more time? š
13:16:57 <peter1138[d]> Hmm, maybe should put all this in a class.
13:17:40 *** emperorjake has joined #openttd
13:17:40 <emperorjake> Sure, I'll have more time tomorrow tho
13:17:51 <truebrain> Whenever you have some time; it would be appreciated š
13:18:18 <truebrain> just give me a poke when you have some š
13:20:35 <xarick> can I has 11802 merged? reviewed
13:34:23 <truebrain> been willing to do that for years, but finally ... š
13:37:38 <truebrain> lol @ 6377 .. peter1138[d] asks very clearly, what needs changing, but the answer is evasive š So now I am back looking at what actually needs changing š
13:38:29 <truebrain> /me clicks AI settings
13:38:41 <truebrain> `global-buffer-overflow`
13:38:57 <truebrain> guess I first need to fix another issue š
13:40:22 <truebrain> `0x55dcffd0f808 is located 24 bytes to the left of global variable '_cust_currency_desc'`
13:40:22 <truebrain> `0x55dcffd0f808 is located 16 bytes to the right of global variable '_settings_selection_desc'`
13:41:39 <truebrain> that indeed is very odd code
13:42:16 <truebrain> `AIConfig::GetConfig(this->selected_slot)` .. selected_slot can be `INVALID_COMPANY`
13:42:22 <truebrain> but `GetConfig` does no check for that
13:43:01 <truebrain> the worst part ... the "config" for `INVALID_COMPANY` is used as if nothing happened
13:43:13 <truebrain> weird code .. let's see ..
13:44:38 <peter1138[d]> I wonder if we should use `.at()` more to let the library throw an exception.
13:45:06 <peter1138[d]> (Not sure if it applies in this particular case)
13:45:19 <truebrain> these are the old C++ functions, where we still threw pointers around
13:45:28 <truebrain> `AIConfig::GetConfig` should return `AIInfo &`
13:45:42 <truebrain> so the problem is a bit deeper actually
13:45:45 <xarick> oh, you dealing with stuff I'm familiar with
13:45:57 <peter1138[d]> ^^ it's his fault
13:46:01 <xarick> just need to refresh my memory
13:49:59 <xarick> oh, 6468 was fixed in the wrong manner, basically because I fail at explaining things... it removed a feature
13:53:29 <xarick> is that going to ruin configs set before the game has started?
13:54:07 <xarick> companies don't exist, but the config needs to exist for invalid companies, they're yet to start
13:54:37 <truebrain> seems reading is hard for you, but maybe, just so maybe, read the text?
13:55:17 <xarick> I'm like 85% certain something's gonna break
13:58:35 <_glx_> yeah the code was safe, just ugly
13:58:56 <truebrain> but if reading is too hard for you, it is easier to go OMG OMG OMG OMG OMG and make panic for ..... I dunno š
13:59:13 <truebrain> btw, it is really nice running with clangs address sanitizer
13:59:20 <truebrain> it is a bit slower, but it does pick up on these kind of things
13:59:21 <xarick> okay, it's fine, it works
13:59:28 <peter1138[d]> How do I enable that? š
13:59:39 <truebrain> `CC=clang CXX=clang++ CXXFLAGS="-fsanitize=address" cmake .. `
13:59:56 <_glx_> I once tried address sanitizer in VS, didn't end well š
14:00:17 <truebrain> I stole this from _jgr_ btw; isn't my idea, running the game like this š
14:01:35 <xarick> might take a look at game_gui.cpp
14:01:42 *** Flygon has quit IRC (Remote host closed the connection)
14:01:47 <xarick> since it's almost a repetition of ai_gui.cpp
14:02:29 <truebrain> since when are GameScripts based on companies?
14:02:41 <truebrain> I must have missed that memo
14:03:20 <xarick> const GameConfig *config = GameConfig::GetConfig();
14:03:43 <_glx_> if you can open the game config window, then you have a valid game config š
14:05:45 <_glx_> and this overloaded GetConfig() does ` if (*config == nullptr) *config = new GameConfig();`
14:05:57 <_glx_> so it can't return anything invalid
14:06:41 <peter1138[d]> Hmm, wasn't there a way to ++ on an enum?
14:06:49 <truebrain> don't we have a declare for that?
14:07:21 <_glx_> and everywhere there's a mix of AIs and GS we never pass DEITY to the AI stuff
14:07:57 <peter1138[d]> We have `DECLARE_ENUM_AS_BIT_SET` which is not the right thing.
14:08:11 <peter1138[d]> And the new `DECLARE_ENUM_AS_ADDABLE` which does not allow for this.
14:08:34 <xarick> when was the ... start date removal done?
14:08:52 <xarick> need to verify if you cleaned something I used as a workaround
14:09:04 <peter1138[d]> It was made into something that works.
14:09:38 <peter1138[d]> Ah, .. ADDABLE doesn't work because 1 isn't an enum value.
14:09:59 <peter1138[d]> DECLARE_POSTFIX_INCREMENT
14:10:04 <xarick> somewhere in make settings live, think that's the name... I added some lines to force the config to push the start_date to random ais
14:10:08 <peter1138[d]> I missed it because it's not DECLARE_ENUM_POSTFIX_INCREMENT.
14:10:20 <xarick> but now since start_date is removed, that workaround can be removed as welll
14:10:29 <peter1138[d]> It's even in the file I was looking at. Just a bit up.
14:10:33 <_glx_> it most likely is removed
14:11:04 <peter1138[d]> PREFIX_INCREMENT would be nice, to satisfy modern tooling that warns against postfix increment š
14:11:33 <peter1138[d]> I know what to do, I know š
14:13:21 <xarick> nop, you didn't remove it :|, I'll make a PR
14:14:16 <xarick> lines 361-363 in openttd.cpp
14:15:07 <truebrain> hmm .. do I actually want to fix #6377 .. it is kinda nice, that you are forced to use a path in your tarball that makes sense š
14:16:14 <truebrain> `(std::filesystem::path(name).remove_filename() /= link).lexically_normal().string()` .. what the actually fuck does that do ..
14:16:18 <truebrain> I hate `std::filesystem` ..
14:16:35 <truebrain> mostly the `/=` is .. weird
14:16:36 <_glx_> xarick: I see nothing about start_date here
14:17:05 <xarick> It's my code, I know what it was supposed to do
14:17:15 <xarick> it's useless now without start_date
14:18:41 <LordAro> truebrain: that is very odd
14:18:57 <truebrain> LordAro: happy it is not just me š
14:19:05 <LordAro> though on the whole i do like / as a concat operator
14:19:09 <xarick> some places say lines 361-363
14:19:21 <LordAro> it does mean /= looks a bit odd though
14:20:14 <truebrain> I am going to leave that piece of code alone š
14:20:26 <truebrain> it looks scary .. and I hope whoever wrote it, tested it š
14:21:13 <_glx_> yes nothing to do with start_date
14:21:26 <_glx_> it's just to initialize
14:21:32 <LordAro> i'd say it suffers from the common issue of just trying to do too much on a single line
14:21:42 <LordAro> rather than anything specific about filesystem
14:22:07 <xarick> it was a workaround to push the start_date for random ais, otherwise they wouldn't have that option once the game started
14:22:33 <truebrain> LordAro: my issue would be that it is, I guess, allowed to assign to a std::filesystem::path, without it being a variable
14:22:36 <truebrain> my head just spins š
14:22:42 <truebrain> but I agree, that whole line just does too much
14:25:30 <xarick> what's the commit that removed start_date, need to link it on my PR
14:26:13 <peter1138[d]> More importantly, link to the PR that added the workaround for start date
14:28:20 <truebrain> why are you doing his work? š
14:28:48 <talltyler> Iām stuck on mine š
14:29:19 <talltyler> Trying to get one timer to return a bool without making all timers return bools is...confusing. Templates are hard.
14:30:52 <LordAro> truebrain: not very different from (foo = Bar()) == NULL construct?
14:31:16 <truebrain> LordAro: except that `foo` is a variable. This is more like `(Foo() = Bar()) == nullptr`
14:31:35 <LordAro> references, i suppose
14:31:58 <LordAro> xarick: if you need it in your PR, it should be in your PR
14:32:03 <LordAro> don't make it a separate one
14:33:29 <xarick> and linked to the PR that removed start_date
14:33:49 <LordAro> maybe i'm misunderstanding, but i don't see why #11854 exists
14:34:10 <LordAro> clearly i am misunderstanding
14:34:14 <talltyler> LordAro: It seems to be a cleanup PR of something no longer needed
14:34:24 <_glx_> it exists because it was needed before the start_date removal
14:36:08 <_glx_> start_date was a weird "virtual" setting
14:36:20 <_glx_> happy we removed it š
14:36:35 <peter1138[d]> Not much context, mind you.
14:37:03 <truebrain> I am sorry for ever adding it š¦
14:37:16 <truebrain> I am not sorry for fixing a 9 year old bug!
14:37:36 <_glx_> hey it looked like a good idea, but it backfired
14:37:44 <truebrain> I am however a bit annoyed on the frosch123 of 7 years ago for being so vague in his comment š
14:39:09 <frosch123> what is vague about it?
14:39:36 <truebrain> "what needs to be removed?" - "well, the problem is, blablabla" .. never actually answers the question! š
14:39:43 <truebrain> but nothing had to be removed š
14:39:54 <truebrain> don't dare to say it took me a tiny bit too long to realise that š
14:40:12 <truebrain> guess the work of mister A also never happened
14:41:34 <frosch123> A worked on replacing paths with std::string or some custom pre-standard std::fs::path. quite possible that it is done by now by someone else š
14:42:01 <truebrain> our file i/o is still a bit messy š
14:42:22 <frosch123> either way, the essence of that ticket: ignoring the tar file name and only using the tar-inside path was a feature once (for old 32bpp), now it is a bug
14:43:15 <_glx_> ah yes from the time grf didn't support 32bpp
14:43:15 <truebrain> frosch123: I know I know, no need to be all serious about my mockery of your 8 year old reply š š
14:43:30 <frosch123> i think there is also some obscure use case: it was possible to put the original grfs into some place (inside a tar), which is not next to the .obg
14:43:35 <truebrain> _glx_: worse, the time 32bpp were PNGs in a folder š
14:43:41 <frosch123> no idea whether that is still possible, or even useful
14:44:30 <frosch123> i am not sure where our installers puts the original graphics .obg, and where users are supposed to put the original .grf
14:44:59 <peter1138[d]> Original graphics not alongside the obg is pretty normal I think.
14:45:18 <_glx_> there's 1 annoying thing with original sounds or music, it's impossible to have both DOS and WINDOWS ones
14:45:42 <peter1138[d]> My basesets are in ~/.local/share/openttd/baseset. The ob* files are not next to them.
14:45:58 <_glx_> same, mine are in documents
14:46:30 <peter1138[d]> You can can have both DOS and WINDOWS by changing the 4 letter code in the obm/obs file.
14:46:46 <peter1138[d]> However, the game will then list both, even if you only have one available. The other will be "missing files"
14:49:39 <_glx_> provided .obX are in installation folder, but the baseset can be anywhere in search path
14:57:25 <truebrain> okay, with my PR the interactions of extracted tars and packed tars slightly changes
14:57:52 <peter1138[d]> Hmm, what do I name a shade that is lighter than lightest? š®
14:59:25 <truebrain> yeah, so normally you could "shadow" a file in the tarball by having the "dirname/file" on your disk
14:59:31 <truebrain> now you also have to prefix it with the tarball name
14:59:41 <truebrain> so it might be that something that worked on people their computer, breaks with my PR
14:59:49 <truebrain> although that would already have been a bit weird thing to do
15:00:24 <_glx_> I think it's very rare to have both packed and unpacked
15:00:42 <truebrain> yeah, and I talk here packed vs unpacked, with modified content
15:00:48 <truebrain> with my PR, you see them as 2 AIs, for example
15:00:52 <_glx_> usually I add .bak to the packed when I unpakc
15:00:55 <truebrain> before my PR, they merged together, in some random order
15:01:11 <truebrain> so my PR is still good, as it removes the randomness of it all
15:01:14 <_glx_> to be sure it picks the right one
15:09:25 <peter1138[d]> I had a go at 7675.
15:09:29 <peter1138[d]> It's not possible š
15:09:43 <peter1138[d]> Escher would be proud.
15:09:46 <truebrain> is it the same as mentioned in the known-bugs?
15:09:57 <talltyler> truebrain: Any suggestions on how to get TimerGameCalendar::Elapsed to return true? I can't figure out how the template works to figure out what I need to duplicate or overload.
15:10:10 <peter1138[d]> You can improve some of the choices, and break others.
15:10:13 <truebrain> `void` -> `bool` for all cases of `Elapsed` š
15:10:26 <truebrain> peter1138[d]: mind writing that in the ticket and closing the ticket?
15:10:50 <_glx_> yeah ignored return value is equivalent to void š
15:12:12 <peter1138[d]> Trying to find my patch first š
15:13:48 <locosage> it might be possible to fix 7675 with some combination of bb and/or sprite sorter changes
15:13:59 <locosage> but it needs an extensive test set before any changes can be made
15:14:38 <frosch123> the pillar-belowe-bridge is impossible to fix. the front-pillar-of-catenary may be possible
15:14:53 <frosch123> i'll post in the issue
15:16:04 <xarick> this assert I added in VisitWaterRegionPatchNeighbors, is catching some funky stuff!
15:16:04 <xarick> assert(water_region_patch.label != WATER_REGION_PATCH_LABEL_NONE);
15:16:37 <xarick> my AI managed to trigger it
15:17:07 <truebrain> frosch123: thank you
15:21:43 <peter1138[d]> Seems to have been a rabbit-hole journey at least.
15:22:52 <frosch123> at least it proves the point that bounding boxes should never have been exposed to newgrf š if bridges or vehicles could define their own BB, none of these fixes were ever possible
15:23:40 <frosch123> maybe we can detect from station grf bounding boxes, whether things are supposed to be drawn in back or front, and then ignore the grf-defined BB and just use our own
15:28:22 <peter1138[d]> All those are better.
15:29:29 <peter1138[d]> The further edge cases happen when vehicles are involved, of course.
15:30:38 <peter1138[d]> frosch123: For simple boxes off to the side it usually works fine though.
15:32:35 <xarick> Kuhnovic, I have a question for you
15:33:18 <xarick> when VisitWaterRegionPatchNeighbors is called, is the water_region_patch garanteed to always have a label != 0?
15:33:26 <truebrain> kuhnovic: yes. So you do fully understand š
15:33:44 <kuhnovic> truebrain: Well no, because I don't understand why you'd need that :p
15:33:44 <truebrain> if you don't, you get a "Savegame is corrupted" if you try to load a newer savegame in an older OpenTTD
15:33:48 <truebrain> instead of the "version not compatible"
15:34:48 <truebrain> in the old days it was simple: always update the version if you change anything about the way savegames are stored. With the table-header approach, we got a bit more flexibility, but in general, if you change the structure as a whole, bump the savegame
15:34:50 <kuhnovic> xarick: That should be the case yes. A tile with label 0 means "has no water", so it should never pop up as a neigbour
15:34:51 <truebrain> numbers are cheap š
15:34:59 <peter1138[d]> Hmm, I guess it's possible the changes I made are still preferable to the current way. Even if not perfect.
15:36:26 <kuhnovic> Ok makes sense, a savegame bump doesn't hurt
15:36:34 <truebrain> just a bit more user-friendly š
15:36:51 <truebrain> and it feels like you are trying to hide this chunk once existed; don't. It is fine. things happen š
15:37:04 <truebrain> it is now part of our history š
15:37:22 <_glx_> not the first chunk disappearing š
15:37:40 <_glx_> maybe the shorter lived one š
15:37:51 <kuhnovic> xarick: That ain't good. Need to look into that.
15:37:54 <xarick> gonna try put the assert after the GetUpdatedRegion, see if it makes a difference
15:38:03 <truebrain> _glx_: shortest, I would claim! Which is an achievement š
15:38:50 <talltyler> truebrain: Like 13.2.1? š
15:39:03 <peter1138[d]> I also have a C++ version of TICC/TOCC which uses "RAII" to work. Bit nicer than than the macros.
15:39:06 <truebrain> talltyler: ssssttttttt
15:39:23 <_glx_> anyone remember 0.4.0.1 ?
15:39:25 <truebrain> peter1138[d]: I am in no way, shape or form shocked you have a patch š
15:39:34 <truebrain> but that sounds nice š
15:41:23 <kuhnovic> I suspect it has something to do with this part of VisitAdjacentWaterRegionPatchNeighbors . There's no checking if label 0 is ever added...
15:42:31 <xarick> what I fail to understand is... how did it become 0?
15:44:14 <kuhnovic> 0 is the default. So I suspect something went wrong in the labeling process.
15:44:59 <kuhnovic> But the real test is: does your visit function ever get called with label 0?
15:45:05 <_glx_> assert it's not 0 before adding to see when it happens
15:45:23 <xarick> this is on master, with just that assert added
15:45:29 <xarick> so, it's not just on my code
15:46:29 <_glx_> if it's not supposed to ever add label 0, it's the proper way to assert that
15:46:40 <kuhnovic> Do you know which tile it is? And do you have a savegame (preferably without a million AIs in it) ?
15:46:52 <xarick> it's the ship on the picture
15:47:08 <xarick> and bam... triggers the assert
15:47:20 <kuhnovic> Again, savegame would help a lot :p
15:47:39 <_glx_> asserts are nice, but should be in the right place š
15:48:15 <xarick> not sure if ludiaiafterfix in bananas can do this crash
15:48:49 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
15:50:29 <kuhnovic> Also try saving and reloading. If that solves the issue then we have desync problems
15:52:33 <xarick> Download LudiAiAfterFix v20 from bananas, configure so it won't build road vehs and aircraft, then wait a bit for a crash, you need that assert line in there too
15:53:14 <kuhnovic> I want a savegame š
15:53:44 <truebrain> that was an interesting triage, #9722
15:56:36 <kuhnovic> Thanks. I need to go soon, but I will have a look at it tonight
15:56:47 <truebrain> fix up your PR first please š
15:57:07 <truebrain> (not before leaving, but before delving into this problem š )
15:58:08 <kuhnovic> Will do that too š
15:58:09 <talltyler> Ugh I just rebased yesterday and there are already merge conflicts. Stop changing things! š
16:01:11 <truebrain> glad you figured out how to change a void into a bool talltyler š
16:01:42 <talltyler> The template was less scary than I thought, only IntervalTimer needed changing and not TimeoutTimer
16:01:56 <talltyler> And TimerManager wasn't a problem like I thought it might be
16:02:10 <truebrain> templates are simple š
16:02:31 <talltyler> Visual Studio's errors aren't always helpful with templates so I need to use my own brain like a smart person or something
16:02:52 <peter1138[d]> That's standard for templates š
16:03:31 <_glx_> yeah compiler are too verbose and at the same time don't really say what is wrong š
16:04:29 <kuhnovic> xarick: Is this savegame supposed to show the problem right away? I see no ships
16:05:03 <xarick> no, let the ai build a ship, have it visit a dock, and on departure it should trigger the assert, did you add the assert line code?
16:05:13 <_glx_> oh a usual wait for some years š
16:05:21 <xarick> nah, about 1 game month max
16:05:49 <xarick> I wonder if it's related with the check reverse?
16:07:04 <xarick> maybe the tile that is passed is a hacked one with no water, hmm
16:07:38 <truebrain> sorry talltyler, seems you are actually still confused what templates actually are š
16:07:57 <truebrain> but a sentence like `There is an optional return value` should raise all kinds of alarms š
16:08:12 <truebrain> unless it is actually a `std::optional<>` ofc š
16:08:26 <truebrain> anyway, hope my comments help you understand a bit more what is going on; if not, yell, and I use a bit more words š
16:08:53 <_glx_> well std::optional for a bool would be weird š
16:08:53 <kuhnovic> xarick: Shouldn't be
16:09:11 <truebrain> _glx_: not really. Yes / no / unknown is a valid tristate
16:09:36 <truebrain> Just not what he was looking for š
16:09:55 <xarick> there's some code about "walks back one tile to where the ship came from"
16:09:56 <peter1138[d]> Totally weird. The tristate is yes, no, file not found.
16:10:34 <talltyler> Well, the trouble with making the return value consistent is asking what level of progress counts as "true". For TimerGameCalendar it's date_fract, but not sub_date_fract
16:10:57 <truebrain> why are you concerned with implementation details in the documentation of the class? š
16:11:09 <truebrain> the fact sub_date_fract exists is irrelevant to anyone but the implementation š
16:11:17 <xarick> and if I recall, doing a reverse when departing from a dock, can put the ship coming from the pier
16:11:30 <truebrain> from a Timer point of view it is easy to explain: it returns true iff time progressed
16:11:33 <xarick> pier has no water, so label = 0, i suspect this may be it
16:11:52 <truebrain> and as sub_date_fract is not retrievable by anyone but the implementation, it is not part of time going forward
16:12:06 <truebrain> the first smell of time moving forward for TimeGameCalendar is when date_fract is being increased
16:12:42 <kuhnovic> Xarick, can you try adding an assert in the visit function (the one used by the pathfinder) and see if you can hit that one?
16:13:10 <truebrain> talltyler: it is a common pitfall btw, to overly want to explain everything that happened, especially as you are very happy to finally find a solution to your problem š But often it makes more confusion to the reader š Anything not-public, don't explain it in public function, is a good rule for this š
16:13:36 <truebrain> `Elapsed` is public, `sub_date_fract` is not. So do not mention the latter in the comments of the first, as the caller cannot do anything about it anyway š
16:17:09 <kuhnovic> I mean inside the visit function
16:17:18 <kuhnovic> The one that gets called for each neighbour
16:17:47 <kuhnovic> The AI in the savegame you sent me doesn't create any ships btw
16:17:52 <kuhnovic> Gotta to now. To be continued...
16:18:13 <kuhnovic> Doesn't matter, just somewhere inside that visit func
16:22:14 <truebrain> 3 approvals and counting
16:22:21 <truebrain> can we get more approvals on #11852 please
16:22:33 <xarick> I wonder what kind of neighbours is it passing now
16:23:00 <peter1138[d]> I could merge that before someone requests changes š
16:24:23 <truebrain> so the thing that might be worth adding talltyler , and sorry if you already understood this, but basically what we do here: define a template definition, that tells everyone how the function behaves. After that, we define a few implementations of that template
16:24:44 <truebrain> it is much like having a single class, with a `virtual = 0` method, which is implemented in a few children
16:26:01 <talltyler> I think I get it now. Do I write more descriptive comments for TimerGameCalendar and TimerGameEconomy to specify that I mean date_fract, or leave them to follow the template too?
16:26:19 <truebrain> again, from a caller point of view, you don't actually care
16:26:24 <truebrain> you just want to know whether time progressed or not
16:26:30 <truebrain> with how much? I dunno .. but something is different!
16:26:36 <peter1138[d]> Did this come up before... should we remove `[[maybe_unused]]` where the parameter is definitely used?
16:27:16 <truebrain> talltyler: nice, looks good now. Clean, simple, understandable š
16:27:28 <talltyler> Thanks for your help š
16:27:42 <peter1138[d]> Yes we should, or yes it came up before... silly question from me š
16:27:59 <talltyler> Agh, forgot to fix that one new date_fract that snuck in recently, time to go back to the bottom and rebase everything again
16:28:08 <truebrain> ideally, we let compilers warn when `maybe_unused` is used while it is used
16:28:11 <truebrain> that `maybe` part just sucks
16:28:28 <peter1138[d]> Well, the other way is to remove the name.
16:28:41 <peter1138[d]> But we went with `[[maybe_unused]]`
16:29:05 <truebrain> No clue why; forgot, or didn't pay attention. But I don't mind `maybe_unused`, I do mind you can just slap it everywhere .. that is just wasting my time as reader of code š
16:30:14 <peter1138[d]> So `void OnInvalidateData([[maybe_unused]] int data = 0, [[maybe_unused]] bool gui_scope = true) override` becomes `void OnInvalidateData(int = 0, bool gui_scope = true) override`
16:30:29 <truebrain> haha, `int = 0` š
16:30:39 <peter1138[d]> Yeah, default parameters for you.
16:30:50 <truebrain> I withhold an opinion about whether to remove the name or use `maybe_unused` š
16:31:30 <_glx_> maybe don't remove the name if there's a default value
16:31:51 <peter1138[d]> `void OnInvalidateData([[maybe_unused]] int data = 0, bool gui_scope = true) override`
16:32:16 <peter1138[d]> There's a lot of code to update if we remove unnecessary `[[maybe_unused]]`
16:33:45 <talltyler> Gah, I keep getting an error `Unlink of file 'src/stdafx.h' failed. Should I try again? (y/n)` and cannot type any response. The only way to fix it is to kill the terminal, reboot my computer, and then delete the git lock file, then start over... So frustrating!
16:33:51 <talltyler> This is the fourth time in the last 24 hours
16:35:13 <truebrain> okay, so #9722 is a bit more problematic than I expected ... basically, we are using `_local_company` to detect if terrain generation is still busy, as `_generating_world` can be false, while still in terrain generation .. but there is this small window where `_local_company` is valid, but terrain generation is still ongoing
16:36:31 <_glx_> talltyler: I suggest process explorer, it can tell you which process has a handle on a file
16:39:42 <talltyler> Thanks, will try that next time š
16:39:53 *** Wormnest has joined #openttd
16:40:25 <kuhnovic> xarick: That's by design, it was already like that before I created the water region stuff. I've also wondered why it is the way it is, but it is correct.
16:43:41 <talltyler> Okay truebrain, now that I seem to have fixed the aging bug... how do you want to handle the final review process? Go through PRs one at a time with a fine-toothed comb, with me merging and rebasing as I go? Another test game?
16:45:08 <truebrain> talltyler: If nobody else does, I will look over the PRs, in order, one by one. And we just merge and rebase indeed. Unless someone has a strong opinion about that otherwise
16:45:23 <truebrain> but another test game feels pointless; chances of gathering more information from that, are low
16:46:12 <truebrain> and "fine-toothed comb" is more a "it looks fine"
16:46:22 <truebrain> like with ship PF, the actual problems are only found AFTER merge š
16:46:28 <truebrain> that is just how it is š
16:46:49 <talltyler> Yep, I will be available to fix all the bugs we find
16:47:27 <truebrain> but okay, I am not that afraid to break a few eggs to get to a better place. Others might be more conservative. So any concerns or counterarguments are welcome š
16:48:08 <truebrain> and otherwise I will make some time tomorrow or so to go through the first PR (again) š
16:48:15 <_glx_> yeah nobody can test or spot all corner cases
16:48:37 <truebrain> in the "old days" we branched off before merging back .. can't say that was a great success either š
16:48:43 <truebrain> most of the NoAI bugs were also fixed when it was in trunk
16:48:54 <truebrain> and we still have bugs in the network stack š
16:49:03 <_glx_> we need many real players to trigger bugs š
16:49:27 <_glx_> and most don't use nightlies
16:49:43 <truebrain> I think most important about NoDL (or what was the name), in its default, you shouldn't even notice it exists in our codebase š
16:50:16 <truebrain> so weeding out bugs can be done with those that dare to use it š
16:50:20 <peter1138[d]> Hm, why was I touching vehicle bounding boxes...
16:50:26 <truebrain> like with cargodist .......... owh wait š
16:50:39 <truebrain> peter1138[d]: because I brought up one of the oldest tickets we have š
16:51:23 <truebrain> did close 2 very old tickets, and solved another 2. So it is a good day.
16:52:12 <locosage> I wish I could just non notice NoDL existance...
16:52:36 <locosage> but will probably be forced to go over it with that fine-toothed comb once its released :/
16:52:51 <truebrain> pre-10000 issues .. they look so cute š
16:54:15 <peter1138[d]> The usual good old positivity from dP there.
16:54:27 <truebrain> The endless argument: please don't progress, as I would have to do work
16:54:34 <peter1138[d]> Feature which everyone wanted for years > but not THAT way
16:55:11 <truebrain> but that what is not new, is also not surprising š
16:56:43 <truebrain> talltyler: first commit I open, has `Conflicts: ..` in the commit message š
16:57:15 <truebrain> not sure how on earth you managed to create a commit message with lines starting with `#`
16:57:18 <truebrain> did not know that was possible š
16:57:29 <peter1138[d]> Some tools ignore that rule...
16:57:38 <truebrain> those tools should be burned
16:57:45 <truebrain> owh, more commits that have that
16:58:00 <truebrain> talltyler: do you intend to rebase or squash?
16:58:14 <talltyler> You strongly recommended squash
16:58:24 <talltyler> And I am fine with that š
16:58:29 <truebrain> then I do not care about those commit messages
16:59:34 <truebrain> well, one check we can do .. _jgr_ , as it doesn't matter that much to us, a PR like https://github.com/OpenTTD/OpenTTD/pull/10700, does it matter to you whether that is rebased or squashed? Anything that would make it a bit easier for you is a small effort on our side
17:00:30 <truebrain> talltyler: you did a check for date_fract us of Calendar btw?
17:00:57 <truebrain> or in general, that because of rebases, you moved everything to the right calenadar still?
17:02:28 <peter1138[d]> Maybe it compiles this time...
17:02:57 <peter1138[d]> Not sure why it should need those extra brackets but they were there in the original.
17:04:35 <truebrain> talltyler: I miss an entry for economy time in `SurveyTimers`
17:04:47 <truebrain> or is that in a later PR?
17:05:00 <truebrain> `DoRandom`, should be economy timers
17:05:15 <truebrain> same as all the `TimerGameCalendar::date_fract` in most network files
17:05:24 <truebrain> at least, I would think debug statements should use economy timer
17:05:26 <truebrain> as that always ticks
17:06:25 <truebrain> similar with saveload.cpp hit. Basically, all `Debug(desync` statements š
17:07:28 <truebrain> `ConGetDate` might also want to print both timers
17:07:44 <truebrain> although .. no, nevermind that one
17:07:46 <truebrain> just forget I said anything
17:10:32 <truebrain> nothing else stands out in that first PR
17:12:15 <locosage> To me the most awkward part about NoDL to me is that I'm the only one running fully functional "frozen" time vanilla servers and yet I won't be able to use NoDL on them.
17:13:51 <peter1138[d]> ^ The only reason we are C++20 now ;p
17:13:58 <talltyler> truebrain: Instead of or in addition to calendar time?
17:15:26 <truebrain> If time is frozen, the calendar time is pointless. But desyncs can still happen
17:15:39 <truebrain> So economy is better suited there
17:17:09 <truebrain> (In my opinion ofc. Feel free to disagree š )
17:18:46 <xarick> the problem is deeper than I thought
17:19:08 <xarick> we're passing patches with water at this point?
17:21:01 <_jgr_> truebrain: It's OK for me either way, I can get the branch out of the PR before it's squashed if I really need to, I doubt it'll be a problem
17:26:51 <xarick> this is really strange
17:27:07 <xarick> those oh_no breakpoints are never reached
17:27:19 <xarick> there's water in the tile
17:27:36 <xarick> but once it's doing pf search, it gets no water on the tile at the other side
17:27:54 <xarick> at the other function*
17:34:08 <xarick> may be when adding docking tiles...
17:39:46 <xarick> yeah... it's pointing at the pier slope
17:45:00 <Rubidium> a "when you see it, you see it" issue
17:45:26 <truebrain> High res clock is weird anyway š
17:45:52 <xarick> the origin adds the destination, but this is still the origin
17:49:52 <talltyler> Okay, there's the debugging changes, economy date in the survey data, and cleanup of the commit messages to not list conflicts š
17:51:23 <talltyler> Oh yeah, one more thing: We need to change the multiplayer server list to show time played in real-time, instead of years. You had previously volunteered to help with that, since it includes changes to whatever the latest game coordinator is called š
17:53:59 <talltyler> Heheh, and I forgot to build before pushing, so let's see if I can do that before it's my turn for CI š
17:55:39 <xarick> seems the problem stems from the pathfinder checking vehicle orders
17:55:56 <xarick> this stumbled on a conditional order
17:56:43 <xarick> the conditional order destination is the dock, literally, the pier
17:56:53 <xarick> and the pf adds that as the origin
18:02:17 <xarick> order_type 4 means ...
18:02:55 <xarick> heh... so it's not even a conditional order
18:15:30 <xarick> difficult problem to solve
18:16:25 <xarick> > * Gets the destination of this order.
18:16:25 <xarick> > * @pre IsType(OT_GOTO_WAYPOINT) || IsType(OT_GOTO_DEPOT) || IsType(OT_GOTO_STATION).
18:16:47 <xarick> waypoints and stations share the same pool
18:17:05 <frosch123> truebrain: you can have the honorary task to check, whether that comment is still helpful in 9 years :p
18:19:34 <truebrain> Haha, with so many words, it has to š
18:19:39 *** gelignite has joined #openttd
18:20:02 <truebrain> The one thing not clear to me from the whole ticket.. is there anything to fix, or is this just what it is?
18:20:07 <peter1138[d]> Now checking my changes with that save š
18:20:08 <xarick> I remember stumbling upon a similar problem back then, determining whether a order->dest belonged to a dock from a docking tile or to a ship depot
18:20:32 <truebrain> Anyway, tnx for reply, maybe someone can now actually fix the ticket š
18:21:33 <frosch123> see the "summary" section: 1 example is unsolvable, 2 are maybe solvable by changing a lot of complex BB stuff, 1 is solveable by changing elrail magic (which I have no idea about)
18:22:11 <truebrain> Yeah ... still no clue whether we should just close it š
18:22:27 <truebrain> The fact something is solveable doesn't mean it is reasonable to do so
18:22:38 <truebrain> But I read peter has things š
18:22:43 <frosch123> did andy set a KPI you have to achieve?
18:23:28 <truebrain> Lolz. No, but with these kind of tickets there is a lot of looking at each other and everyone thinking: this is not going to happen
18:23:44 <peter1138[d]> My things don't really take into consideration the things frosch mentions.
18:24:17 <truebrain> And with the kind of comments in that ticket, it reads to me: nobody is going to tell them we are not fixing this
18:24:51 <truebrain> So maybe rephrase: "solveable" in what measure of complexity? š
18:25:02 <frosch123> yes, that is true, we do not distinguish external/customer tickets from internal ones with dev comments š
18:25:50 <truebrain> frosch123: That would be an excellent idea.. pretty sure a few things would get closed a lot quicker š
18:26:32 <frosch123> well, you would have twice the tickets to start with :p
18:28:01 <truebrain> But okay, not really getting answers, so we will leave the ticket for another 5 years š
18:28:45 <frosch123> at past jobs all tickets were cloned/duplicated. devs could not comment on customer-visible tickets, project people would forward/reword dev-responses between them, and generally filter stuff like "our crappy software does not work like this" or "this is all bob's team problem"
18:29:53 <truebrain> sounds a bit excessive š
18:30:10 <truebrain> btw .. totally unrelated: didn't orudge promise a big party in March? š
18:30:31 <frosch123> yes, though i have a dentist appointment on that day :p
18:30:56 <truebrain> is it on the forums? I never read forums ...
18:31:18 <truebrain> frosch123: pretty sure you can call to those places and get it moved š
18:31:21 <_zephyris> Surely this sorting problem is literally impossible, it's the same kind of issue as the tall vehicles vs. bridges/tunnels. The game relies on an optical illusion, and that will break unless you strictly control the circumstances. I say close it as unsolvable š
18:31:34 <truebrain> Better excuse is: I have surgery that day! š
18:32:06 <truebrain> _zephyris: see, that was the kinda talk I was hoping frosch123 would return; but he is more analytic š
18:32:44 <frosch123> the birthday is on 2024-03-06
18:33:16 <xarick> when was GetDestinationStation() removed from yapf?
18:33:18 <truebrain> but did orudge plan something, and did I just miss the announcement? Again, all these evasive answers of yours š
18:33:35 <wensimehrp> I thought it is 24-03-14
18:33:43 <frosch123> i do not read forums either š
18:33:57 <truebrain> okay, so you are trolling š We really have to introduce the /s here š
18:34:22 <peter1138[d]> peter1138[d]: This is the case that is impossible to solve, btw
18:34:43 <frosch123> my "yes" referred to the "promise", not to any "announcement"
18:34:48 <peter1138[d]> Train needs to be under bridge. Signal needs to be in front of bridge. Train needs to be in front of signal.
18:35:01 <truebrain> frosch123: lol š Fair enough š
18:35:27 <frosch123> we can have a zoom party, and all bake our own cake
18:35:41 <truebrain> pfff, so much effort
18:36:10 <frosch123> march is no outdoor party weather
18:36:13 <peter1138[d]> Maybe we can split signals into lower & upper parts...
18:36:25 <truebrain> anyway, last call, anyone (with some actual arguments) any issues with NoDL?
18:39:32 <frosch123> i checked the forums: there is no party announcement
18:41:35 <frosch123> it's a wednesday, so any events on the exact date won't work š
18:42:07 <peter1138[d]> 14.0 release event?
18:42:27 <frosch123> but maybe lordaro can post, how he spent 2/3 of his life with ottd
18:43:19 <truebrain> peter1138[d]: livestreams and everything? Big party room ... booths with merch ...
18:44:06 <truebrain> right, back to hunting down old bugs
18:44:19 <truebrain> Yeah .. euh ... no clue š
18:44:24 <truebrain> seems that has been the thinking for a few years š
18:47:03 <frosch123> no idea when intentioanlly, and when on accident
18:47:33 <truebrain> the 3rd and 2nd are correct
18:47:37 <Rubidium> I know a big venue in Berlin that's going to do something with trains this year when the weather is usually still good. Too bad they're mostly new trains... And I'm not sure how much tickets will cost
18:47:41 <truebrain> (that they aren't approved)
18:48:04 <truebrain> ticket #469 is a bit odd, that it is still open
18:49:07 <truebrain> where was your briliant text for denying people .. let's see ..
18:51:40 <frosch123> hmm, i did not use "/deny", i guess it makes no difference
18:52:22 <xarick> there is a problem with the mixed usage of DestinationID with StationID
18:52:25 <truebrain> I found it again š
18:52:35 <_glx_> oh the nb_NO one, I saw it on my phone (at least twice) but could not log to github in phone browser to check some things and I totally forgot it when back on the computer
18:52:52 <truebrain> and I just didn't check
18:52:56 <truebrain> not sure if that is better š
18:53:08 <frosch123> oof... that response... got a harsh reaction last ime
18:53:28 <truebrain> it is still funny as fuck š
18:54:11 <truebrain> the ticket alone makes my head spin
18:54:16 <truebrain> the comments didn't improve the situation
18:55:16 <frosch123> that's tracktype compatibiltiy for you
18:56:24 <truebrain> LordAro: ever got to figuring out if #8505 is indeed outdated by now? š
18:56:42 <xarick> could be the ID of a ship depot, not of a station
18:57:01 <frosch123> no idea whether anyone is interested in tracktype stuff, i certainly am not š
18:57:16 <truebrain> so that bug goes back to the freezer for another 3 years š
18:57:34 <truebrain> (I am looking at the "needs triage" bugs š )
18:57:41 <peter1138[d]> Probably just a misunderstanding. They've all moved on to a 'standard' label scheme now.
18:58:00 <peter1138[d]> One of them š
18:58:01 <_glx_> at least 3 standard š
18:58:26 <_glx_> and I think there's is another one being written
18:59:31 <truebrain> let me guess ,that new one is going to solve all problems and make the other 3 irrelevant? š
18:59:53 <xarick> from yapf, when calculating costs
19:00:10 <peter1138[d]> Specifically where?
19:00:16 <truebrain> so I am looking at a bug I barely understand, which has a PR to supposedly fixed it, to read the problem has already been fixed š Sometimes our bugs lead us to special places š
19:01:52 <xarick> i guess not š¦ i swear i thought i saw it before
19:02:29 <xarick> because orders have a dest which can point to either station or depot
19:02:37 <xarick> but now i can't see where
19:10:39 <LordAro> would need to ask _jgr_ , i never really understood what i was doing
19:10:58 <truebrain> Yeah .. I was looking at the bug and PR to realise I don't understand any of this stuff š
19:13:27 <truebrain> ever used keyboard arrows to move around on our map?
19:13:31 <truebrain> if you want to puke, do that
19:13:55 <andythenorth> that 8301 is probably an nmlr or user error
19:14:10 <andythenorth> there is no railtypetable in that context AFAIK
19:14:18 <andythenorth> it's an nml construct that does more harm than good
19:14:32 <truebrain> is this something you can / willing to pick up with george?
19:15:13 <andythenorth> no, my understanding of railtypes is poor
19:15:27 <andythenorth> the grf authors understand it best, they have to explain it to me every time
19:15:45 <truebrain> you are a grf author, sorry to burst that bubble š
19:16:16 <truebrain> so we now have to call you ex-grf-author?
19:16:36 <andythenorth> wonder when I last bananased
19:17:21 <talltyler> Too long ago, we want the new Horse with narrow gauge trains š
19:18:25 <wensimehrp> I have problem compiling IH3 on my computer
19:20:01 <truebrain> funny .. moving 10 pixels per cycle makes arrow scrolling look terrible .. but 50 looks fine (which happens when holding shift)
19:20:06 <truebrain> humans are so bad in small movements
19:22:28 <frosch123> lol, i was aware of arrow key scrolling and people complaining about it not using wasd, but the shift behavior is new š
19:22:41 <truebrain> I found out by looking at the code š
19:23:05 <locosage> even with shift it's slow
19:23:12 <locosage> idk why people use it
19:23:12 <frosch123> add ctrl for even faster?
19:23:41 <peter1138[d]> It's fast on normal map sizes.
19:24:58 <frosch123> ah cppcon... one hour talk, i quit after 10 minutes explaining haskell syntax and defining monads, comments are disabled :p
19:25:03 <locosage> it's slow way of navigating the map
19:25:04 <truebrain> let's see how this one lands š
19:25:45 <locosage> you still need to zoom out, scroll, zoom in
19:25:59 <frosch123> oh, iirc i suggested smooth-scrolling back in the change-defaults-discussion, and it was controversial
19:26:02 <locosage> that's like 7 keys if you do it on keyboaurd
19:26:11 <truebrain> frosch123: why? That is surprising š
19:26:37 <peter1138[d]> Also the intro-game scrolling bypasses smooth scrolling.
19:27:25 <truebrain> haha, the argument I use to enable it š
19:27:44 <truebrain> talltyler: you still carry the opinion of arrow movement? I really think it is a great improvement to enable it, if only just for arrow movement š
19:28:06 <truebrain> (in fact, I was creating a patch that makes arrow movement always use smooth-scrolling, to make me less nauseous when using them š )
19:28:11 <peter1138[d]> Oh I guess. Smooth scrolling is obvious for cursor key scrolling.
19:28:21 <peter1138[d]> But it does affect viewport jumping too.
19:28:55 <truebrain> yeah .. so I was either going for the PR I just created, or making arrow-movement use smooth-scrolling
19:29:11 <truebrain> the one funny thing I find about smooth scrolling and clicking around on the map in debug mode, it shows how long loading sprites take š
19:29:26 <truebrain> the first few times is horribly slow, but after that, it is very okay
19:29:29 <truebrain> goes away in release builds š
19:29:31 <peter1138[d]> Load up a few 32bpp extra zoom sprites for that...
19:30:06 <peter1138[d]> Doesn't help that some of the... prolific... authors don't know how to cut up sprites.
19:30:07 <truebrain> the target-speed for smooth-scrolling is just ever so slightly too fast for my taste, but okay, splitting hairs š
19:30:31 <locosage> frosch123: iirc smooth scrolling was significantly improved since
19:30:38 <peter1138[d]> (So bits of images are duplicated, meaning more pixels to load/decode/draw.)
19:31:04 <frosch123> really, there were changes to smooth scrolling? š®
19:31:19 <truebrain> doubtful; we only improved drawing
19:31:32 <peter1138[d]> Possibly the decoupling between viewport updates and rendering updates.
19:33:13 <truebrain> max speed seems to be 512 tiles per tick
19:33:16 <truebrain> which seems a bit fast
19:33:35 <truebrain> anyway, maybe minimap movement shouldn't use smooth-scrolling
19:33:41 <peter1138[d]> So many overlapping darkening pixels
19:34:10 <peter1138[d]> Not just minimap, also the location button on many things.
19:34:14 <peter1138[d]> It's good at 256x256.
19:34:22 <peter1138[d]> Takes too long at larger sizes.
19:34:23 <truebrain> I find the location button very useful to smooth scroll
19:34:26 <truebrain> then I know where I went to
19:34:43 <peter1138[d]> Probably should move most of the way there in one go, and then just smooth scroll the last little bit.
19:35:00 <truebrain> oof, there are weird bugs with smooth scrolling
19:35:04 <truebrain> maybe I should fix those first
19:35:09 <truebrain> often it doesn't go diagonal
19:36:24 <truebrain> owh, the 2 axis have their own clamping
19:36:28 <truebrain> so they don't stay in ratio
19:36:34 <truebrain> that is just badly coded
19:37:58 <locosage> frosch123: nvm, I wast just trying on a small map
19:38:06 <locosage> on large ones it's still weird as heck
19:38:21 <locosage> doesn't lag though so maybe I got a better pc now xD
19:39:59 <truebrain> now the game wants to start, but doesn't take input control anymore
19:40:35 <peter1138[d]> At least you can debug it š
19:40:48 <truebrain> if with "debug" you mean: restart WSL š
19:41:00 <xarick> wow 88 messages, I only went to eat
19:41:05 <locosage> idk, what's wrong with smooth scrolling on openttd, it's a sound idea in principle but somehow doesn't feel right
19:41:34 <locosage> maybe needs a different easing function
19:41:35 <peter1138[d]> I wrote it, of course it's shoddy.
19:41:50 <truebrain> you wrote it? Yeah, you made a mistake in your thinking š
19:42:23 <truebrain> and my fix doesn't fix it in the way I want it to be fixed .. so I am no better š
19:42:54 <truebrain> ah, no, CoPilot just gave me a terrible suggestion which I blindly accepted
19:42:59 <truebrain> yes, I am that kind of developer now
19:44:39 <xarick> anyways, I found the cause of the bug, but I'm a terrible person at explaining things
19:46:34 <xarick> it adds an origin tile with no water on it
19:47:48 <truebrain> right, that alone is a big improvement to smooth-scrolling š
19:48:01 <truebrain> I think it can be written better, but ... my head hurts š
19:48:01 <talltyler> truebrain: Dunno, disregard whatever I wrote previously š
19:48:45 <talltyler> Iām done for today, will get back to merging and updating tomorrow. Thanks for your help. ā¤ļø
19:49:25 <locosage> rimworld shows arrow when hovering jumpable item so you know where scroll will take you...
19:50:18 <andythenorth> wensimehrp: dare I ask?
19:54:59 <locosage> oh, smooth scroll works faster on pause xD
19:56:08 <kuhnovic> truebrain: Is a simple version bump enough or do I need to add additional logic? Don't think so right?
19:57:27 <peter1138[d]> Busy commit day.
19:57:33 <peter1138[d]> Remember when OpenTTD was dead?
19:57:52 <truebrain> owh, and the nightly was successful \o/
19:58:37 <locosage> oh, on 8x zoom out smooth scroll has 100+ ms lags spikes
19:59:10 <locosage> yeah, just have better pc now so smooth scroll doesn't look like a laggy mess anymore on usable levels
20:00:16 <peter1138[d]> On 8x zoom out I can see the whole map in one go š®
20:00:47 <locosage> I have max zoom out on 2 so scrolling map is actually smooth
20:00:52 <locosage> with just 20ms spikes
20:01:30 <peter1138[d]> So basically pre-load all possibly required sprites just so scrolling is always smooth.
20:01:50 <locosage> I don't think that's sprite cache issue
20:02:23 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:02:25 <locosage> they should all be loaded anyway in vanilla game afaict
20:02:32 <truebrain> for some reason, it would make more sense to me if shift would make the arrow movement go slow, and without it, it would be fast
20:02:42 <truebrain> but okay, with shift, navigating is pretty much okay
20:03:42 <peter1138[d]> I think having to load sprites, decode them, and then re-encode them to what the blitter requires... is the only thing that can cause smooth scrolling to be jumpy.
20:03:43 <truebrain> peter1138[d]: I am okay with 11750; if you can check if you find your comments handled properly, please approve š
20:04:33 <locosage> peter1138[d]: it's way laggier with grf that actually have cache issues
20:05:23 <_zephyris> Is vsync on by default? That's the biggest improvement for map scrolling plesantness for me
20:05:44 <truebrain> timing it with your video refresh helps with a lot of perceived movements š
20:06:02 <truebrain> `int max_scroll = Map::ScaleBySize1D(512 * ZOOM_LVL_BASE);` ... I cannot decypher what `ZOOM_LVL_BASE` has to do with any of this .. hmm
20:06:49 *** Wormnest has joined #openttd
20:07:26 <peter1138[d]> Probably a mistake.
20:07:38 <truebrain> would the idea have been to change that value based on zoom-level?
20:08:56 <peter1138[d]> It was designed for 512 pixels at 1x, but then every coordinate had to be adjusted when we added 2x and 4x zoom in.
20:09:15 <truebrain> so viewport pixels are in 4x, you say?
20:09:38 <truebrain> then `ZOOM_LVL_BASE` makes sense š
20:11:18 <truebrain> okay, I knew my change could be simpler š
20:12:25 <wensimehrp> nmlc ERROR: "generated/iron-horse.nml", line 497730: Unrecognized identifier 'reverse_build_probability' encountered
20:12:25 <wensimehrp> make: *** [Makefile:113: generated/iron-horse.nfo] Error 1
20:12:25 <wensimehrp> 497730: reverse_build_probability: return 50;
20:12:50 <peter1138[d]> wensimehrp: You probably need a newer NML.
20:13:39 <peter1138[d]> That was added to nmlc ~2 months ago.
20:17:21 <truebrain> always nice if people use your actual name instead of nickname š lol
20:18:22 <peter1138[d]> We have actual names?
20:19:03 <peter1138[d]> "Plague-spreader1138"
20:20:06 <truebrain> there .... much more sensible way of solving that š
20:20:12 <truebrain> took me way too long to figure out how that worked again š
20:20:34 <truebrain> hint: the abs() took very long, giving me very funny results š
20:20:48 <LordAro> well that's a very interesting thing
20:21:25 <truebrain> LordAro: lolz; what are you talking about? š
20:21:28 <truebrain> this feels so random š
20:22:10 <truebrain> context is everything
20:22:13 <truebrain> yeah, it is really cool
20:22:16 <LordAro> i am very well known for being lol so random
20:23:41 <peter1138[d]> Trying to remember if the , 4 there is related to ZOOM_LVL_BASE too, or if it was to move (up to) 25% of the way each step...
20:23:45 <peter1138[d]> The latter I think.
20:24:04 <locosage> I probably have bananas client in python somewhere...
20:24:18 <truebrain> peter1138[d]: I assumed it is the gradient, that makes the slowdown happen
20:24:23 <truebrain> where 4 is just a random slowdown factor
20:24:40 <truebrain> a tile is 32pixels wide, right?
20:24:40 <locosage> or maybe not... definitely have game client but surely wouldn't want that in the open due to how many nasty things it can be used for in wrong hands
20:24:51 <locosage> for bananas it's probably less of an issue
20:25:01 <peter1138[d]> 64 from corner to corner.
20:25:16 <peter1138[d]> Or 256 if you talk in 4x zoom š
20:30:46 <peter1138[d]> With Wentbourne, redrawing the main viewport at 8x zoom-out on 2560x1440 screen takes about 200ms.
20:31:20 <truebrain> seems the current speed is roughly 16 pixels per ms in 1x zoom
20:32:00 <peter1138[d]> Down to 130ms if I turn off station signs, town signs, and full detail
20:32:28 <peter1138[d]> "Why does scrolling at 8x zoom out feel laggy"...
20:32:35 <peter1138[d]> Simply because it's drawing a lot, I guess.
20:32:49 <peter1138[d]> And that's ignoring sprites having to be loaded.
20:33:03 <truebrain> frosch123: hmm, division by zero, good point, I did not check. But x and y are never zero, so if x is greater than y, it is never zero .. and otherwise y is never zero .. yeah, magic. But should be fine. Right? š
20:33:46 <truebrain> other way around, if x is zero, y is always bigger, so the first case is never hit. If y is zero, x is always bigger, and the second case is never hit
20:33:50 <truebrain> yeah, we should be good there š
20:34:26 <peter1138[d]> Someone read my comment without responding to it š
20:34:45 <truebrain> he has that tendency š
20:35:00 <peter1138[d]> 50ms rendering time on Wentbourne when scrolling from one side to the other side.
20:35:36 <truebrain> I have something for you in a bit that will help with overcoming scrolling that is a bit laggy
20:35:40 <truebrain> it will still be laggy, but less annoying
20:35:46 <truebrain> but first the other PR needs to merge š
20:35:48 <peter1138[d]> At 4x zoom out, it's 25ms rendering (funny that) so it is smoother.
20:39:18 <truebrain> you need to configure MSVC to use vcpkg
20:39:24 <truebrain> but by all means, update it! š
20:39:54 <truebrain> VS2019 is still able to compile OpenTTD, which does not integrate vcpkg
20:39:58 <truebrain> so there is the duality of it all
20:40:16 <truebrain> /me hands LordAro a bit more OCD
20:40:28 <truebrain> sorry, I jumped to conclusions in my reply š
20:40:51 <truebrain> currently, smooth-scrolling can take 1s to get to its destination
20:40:54 <truebrain> I am going to up that to 0.5s
20:43:12 <xarick> ewww... I stumbled upon a big flaw
20:43:36 <xarick> remove dock, but let the order to it stay
20:44:32 <xarick> it only works on the assumption that there's always water
20:45:15 <truebrain> peter1138[d]: do we have this 64px per tile somewhere in a constant that you know of?
20:46:02 <truebrain> `TILE_PIXELS` is 32
20:46:10 <kuhnovic> xarick: I don't follow... what do you mean with RIP water region
20:46:14 <truebrain> so twice that, I guess š
20:46:51 <xarick> probably not rip, but... how is it gonna determine a patch
20:47:08 <truebrain> I see Marvin entered the chat again
20:47:14 <truebrain> (referencing HHGTTG)
20:49:28 <kuhnovic> xarick: Like it always does? Something has to invalidate the region (the deletion of the dock should). Then the next pathfinder run updates the water region and new patches will be identified. But I think you have to explain your situation a bit better, a screenshot would help.
20:50:30 <xarick> the facility DOCK is removed, the station says, it doesn't add an origin
20:51:38 <peter1138[d]> What is the problem that occurs?
20:53:50 <peter1138[d]> TILE_PIXELS is the height in pixels at ZOOM_LVL_BASE, I guess.
20:54:21 <truebrain> I had the same assumption; so this will be fine š
20:56:20 <truebrain> that PR compensates for much of the lag during scrolling š
20:56:27 <xarick> im testing what's happening
20:56:27 <truebrain> still not smooth, ofc, but at least less annoyingly so š
20:57:27 <xarick> well, looks okay apparently
20:57:54 <xarick> it tells the pf to start searching with no origin, it bails out immediately
20:58:42 <peter1138[d]> truebrain: Ah, so it'll still be laggy, just constant-ish time.
20:58:43 <kuhnovic> Yup, zero start nodes (remember, high level pf runs in reverse) so nothing to expand on
20:58:57 <truebrain> peter1138[d]: yup. Now takes ~0.5s to get from left to right, no matter how laggy .. give or take
20:59:39 <peter1138[d]> Wentbourne debug, let's see...
21:00:19 <peter1138[d]> Well that still takes ages at 8x zoom out š
21:00:33 <peter1138[d]> But at normal zoom in it's fine.
21:00:49 <peter1138[d]> (And Wentbourne is never usable in a debug build)
21:00:51 <locosage> smooth scrolling can probably just teleport after it reaches some speed as that slideshow isn't useful
21:00:57 <locosage> havent't tried new pr though
21:01:02 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:01:29 <xarick> wondering if CalcClosestStationTile could be used
21:01:53 <truebrain> that really should put the viewport on the destination instantly
21:02:32 <peter1138[d]> Takes about 1 second at 2x zoom in, not 0.5s
21:02:36 *** gelignite has quit IRC (Quit: Stay safe!)
21:02:43 <truebrain> yeah, sorry, the 0.5 is at max speed
21:02:47 <truebrain> there is a slowdown at the end
21:03:09 <truebrain> so that is 1/4th of the value
21:03:37 <truebrain> okay, I worded that really poorly š
21:03:46 <truebrain> the maximum speed is now depending on the time
21:03:54 <truebrain> I wonder if we should also make the division depend on it š
21:04:59 <peter1138[d]> It's hard to know how far to screen when the feedback on how long it takes happens after you've done it.
21:05:17 <truebrain> initially I tried to track how long movement was happening
21:05:22 <truebrain> but that is another can of worms to resolve
21:06:58 <truebrain> instead, reworded the PR a bit to reflect what it actually does š
21:09:14 <peter1138[d]> That distinction is not very useful tbh.
21:09:29 <truebrain> maybe when we started with c++
21:09:35 <truebrain> as, scary, templates, ooooooeeehhhhhhh
21:09:55 <xarick> I really didn't wanna rely on st->facilities
21:10:04 <peter1138[d]> vehicle_base.hpp I guess?
21:10:18 <truebrain> right, maybe another day I give the division of smooth-scrolling a crack, to make that time-based too .. but for today, my head already hurts from all this math š
21:11:09 <truebrain> not sure if it should be `max(Map::SizeX(), Map::SizeY())`, or the `Scale1D` variant
21:11:25 <truebrain> the latter compensates for weird map ratios a bit better, I guess
21:13:34 <truebrain> changed my mind, Scale1D it is š
21:14:16 <truebrain> 167 issues open .. analyzing, fixing, etc takes such a long time š
21:21:57 <truebrain> let's see if this greates some momentum š
21:22:30 <truebrain> I feel frosch123 just ignores private DMs. So sad.
21:23:42 <frosch123> on discord? no i don't. you sent one at 7:50
21:23:55 <truebrain> owh, so you just don't reply. No, I get it š
21:23:58 <truebrain> Sorry, I am trolling š
21:24:12 <truebrain> In a normal company this would be unacceptable š Too many PRs without a ticket! š
21:25:23 <peter1138[d]> Just proof that we never listen to players.
21:25:23 <Rubidium> or maybe too many PRs for the same ticket?
21:25:46 <truebrain> Rubidium: lolz; that is one way of looking at it too yes š
21:31:44 <peter1138[d]> Maybe I need to start opening issues and then updating PRs to refer to them :p
21:33:39 <truebrain> waste of your time; better spend in collecting more patches locally š
21:37:01 *** Wormnest has joined #openttd
21:38:17 <peter1138[d]> $ git branch | wc -l
21:41:55 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:43:42 <xarick> I'm not sure what's the best way to approach this
21:45:02 <peter1138[d]> Explain the problem clearly, to start with.
21:45:05 <xarick> check if the tile has tracks? and if not, just don't add the origin
21:46:12 <xarick> but in the bug report, the origin was actually a dock, it just didn't look at the docking tiles
21:50:17 <xarick> btw, Kuhnovic makes v->dest_tile as an origin, makes it even more difficult to explain
21:51:38 <xarick> ship wants to go to the dock it just departed
21:51:38 <peter1138[d]> Did you miss the part of about explaining the problem clearly?
21:53:25 <_zephyris> truebrain: Just means the long-term strategy of promoting self-sufficiency of players to address issues or provide new features is working š
22:07:35 <andythenorth> `VEHICLE_FLAG_DISABLE_EXCLUSIVE_PREVIEW` should disable exclusive preview?
22:08:03 <andythenorth> hmm but I also have `VEHICLE_FLAG_SYNC_VARIANT_EXCLUSIVE_PREVIEW` flag set
22:08:35 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:09:44 <peter1138[d]> The disabled exclusive preview will not happen at the same time.
22:29:54 <truebrain> 151 left, almost there!
22:32:13 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:39:30 <xarick> probably wrong by using Station and not BaseStation
22:45:31 <xarick> docking_station is not a member of BaseStation š
22:47:42 <_zephyris> Chipping away. What a rabbit hole.
22:47:57 <andythenorth> peter1138[d]: it didn't š
22:48:04 <andythenorth> it happened at a different time š
22:52:04 <peter1138[d]> Ah yes, exclusive preview sync just means they get activated when the parent exclusive preview happens.
23:00:36 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:05:48 <xarick> DestinationID ... too ambiguous
23:06:20 <_glx_> it's just any valid destination
23:06:30 <_glx_> depot, waypoint, station
23:07:25 *** Wormnest has joined #openttd
23:07:57 <xarick> main issue is to know which
23:08:12 <xarick> independently of order type
23:19:32 <peter1138[d]> Sadly std::optional requires distinct types, and our StrongTypes cannot be used in all the places that StationID and DepotID are used.
23:35:50 <peter1138[d]> Er, not optional, variant š
23:39:26 <peter1138[d]> Hmm, maybe it can.
continue to next day āµ
