IRC logs for #openttd on OFTC at 2024-01-20
⏴ go to previous day
00:13:18 <_zephyris> Woop, looks pixel perfect to me.
00:13:52 <_zephyris> Shame RTL is broken, presumably right<left and bottom<top rectangles aren't filled.
00:15:42 <_zephyris> Hmm, maybe 1px off on the L shadow
02:49:13 *** Link has quit IRC (Remote host closed the connection)
03:09:53 *** Wormnest has quit IRC (Quit: Leaving)
03:40:54 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:48:15 *** APTX has quit IRC (Ping timeout: 480 seconds)
06:21:55 *** D-HUND is now known as debdog
06:31:24 *** wensimehrp has joined #openttd
06:31:24 <wensimehrp> I just noticed from zephyris's picture that the lines for the tree-view system isn't scaled. I run the game on a 2k display under 2.2x scale and the lines looks like this:
06:32:32 <wensimehrp> Ovbiously the lines are much thinner than the the lines in the first image.
06:44:01 *** APTX has quit IRC (Remote host closed the connection)
07:32:13 *** ChanServ sets mode: +v tokai
07:38:55 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:44:34 <_zephyris> One of the things I was fixing 🙂
09:18:08 <truebrain> Question of the day: `uint8_t random_bytes[32]` vs `std::array<uint8_t, 32> random_bytes` .. does it matter, and if so, why? 🙂
09:30:52 <LordAro> bounds checks are easier, i suppose
09:32:06 <truebrain> nothing a `sizeof` doesn't already do, ofc
09:32:52 <truebrain> fun fact btw, GCC is the only compiler in our CI that thinks `sizeof` is not a `constexpr`
09:37:18 <truebrain> (I cannot link that in the ticket, as it will cross-link the tickets over repositories, which annoys the fuck out of me, as it is not interesting to know from the other side 😛 )
09:41:08 <truebrain> lol, all I read on the Interwebz also say: "is a good idea if you have C++11", but they do not mention any reasoning
09:43:28 <truebrain> most comments focus around passing an int[] as parameter, and then trying to get the length. Which of course is something you shouldn't even want to
09:49:22 <truebrain> lol ... too much python .. forgot a `;` ... lolz
09:55:21 <truebrain> Rubidium: owh my, indeed .... GitHub did not render that in any way I preceived that 😄
09:56:04 <truebrain> hmm .. the downside of that commit I just send, is that I have to move this into a header
09:56:59 <truebrain> which is bad; so I would still need to keep the old function around, and I could add a wrapper in the header ..
09:57:25 <Rubidium> for the purpose of RandomBytesWithFallback, I think the span version is the better solution
09:58:08 <Rubidium> as it would also allow you to put the random bytes into any other container that can be (automatically) converted to a span
09:58:21 <truebrain> the main thing that triggered me, is that it is kinda better to not initialize `random_bytes`. It should be pointless, as the content is rewritten, but in case of a bug, random values are better than zeros 😛
09:59:11 <truebrain> right, that was a fun exercise 😄
09:59:23 *** thelounge345 has joined #openttd
10:05:37 *** thelounge345 has joined #openttd
10:06:30 <Rubidium> how bad would it be when a unit tests fails occasionally (about 1 in 10**77 runs)
10:06:51 <truebrain> I would ask: how do you know that specific number?
10:07:04 <truebrain> next: I am sure they fail more often because of cosmic rays
10:10:39 <Rubidium> I'm contemplating making a unit test that sets InteractiveRandom to a known state, and then get 32 bytes of random using TB's new function. Then I'd reset InteractiveRandom to the same state, and check whether not all bytes match (i.e. I did not get the fallback solution). So, there a 2**(32*8) chance that the "OS" random returns exactly what the fallback would return and then it'd fail
10:10:42 <truebrain> HA! A signature created via Python I can validate via monocypher 😄 (I always think it is important to have signatures created by another tool than checked, just to rule out any implementation bug on either side 😛 )
10:11:11 <truebrain> like winning the lottery, I would say
10:11:23 <truebrain> but what would the unittest proof?
10:11:39 <truebrain> that there is no missing "return" hiding? 😛
10:11:43 <Rubidium> that we did not forget a return something
10:12:06 <truebrain> if you do it, at least initialize the random-state to zeros, and also check it is not still zero
10:12:20 <truebrain> so now you have 2x the chance of the unittest breaking
10:12:47 <truebrain> also, that unit test will always break if there is no cryptosecure random generator for that OS
10:13:06 <truebrain> like on any system with a (very) old glibc
10:13:50 <truebrain> (which would happen to be `linux-legacy`)
10:13:52 <truebrain> so it is a tricky unit-test
10:18:52 <truebrain> talking about RNGs, maybe we should upgrade InteractiveRandom to use a proper RNG 😛
10:22:12 <Rubidium> hmm, if that happens with linux-legacy, then maybe it's not a good idea to make the test. Though, should we then spam the console of those users with the message that it has no strong random instead of just showing it once with 0 debug level and afterwards at debug level 1?
10:22:39 <truebrain> just copied that code; didn't actually think about it 😄
10:23:06 <truebrain> first, let's see what the internet thinks about SecRandomCopyBytes vs arc4random ...
10:23:51 <truebrain> E_TOO_MANY_RANDOM_GENERATORS
10:23:57 <truebrain> most are attached to `/dev/random` these days
10:24:01 <truebrain> but even of that you can't be sure
10:28:41 *** michi_cc[d] has joined #openttd
10:28:41 <michi_cc[d]> truebrain: I don't pretend to know anything about this stuff, but it does say `cryptographically secure` 🙂 But if better sources say different, I'm good with that, too.
10:29:08 <truebrain> yeah, I already had it in the PR description, but monocypher made a list of what function to use for what OS
10:29:15 <truebrain> so .. I suggest we stick with that. I really do not know 🙂
10:29:46 <truebrain> I really wish there was a library for this, but all that I found were weird or missing non-deprecated support for Windows
10:32:06 <truebrain> Rubidium: fixed the "only warn once" 🙂
10:33:04 <truebrain> still not sure if "misc.cpp" is the right place for this function, but okay
10:34:32 <truebrain> hmm, we just have a `random_func.cpp` .. /me moves stuff
10:37:35 <truebrain> there, that makes more sense
11:11:59 *** Flygon has quit IRC (Read error: Connection reset by peer)
11:26:15 <xarick> okay, I think I found the bug for real... it's a matter of pointers which is my weak spot
11:26:44 <xarick> pointer or reference...
11:30:44 <xarick> for some reason the region is initialized, and it should not be
11:36:35 <xarick> I wish Kuhnovic was here... VisitWaterRegionPatchNeighbors needs a assert(water_region_patch.label != WATER_REGION_PATCH_LABEL_NONE);
11:52:18 <xarick> asserts on mine, doesn't assert on Kuhnovic's
11:59:30 <truebrain> let's see if disabling PCH for those files work
12:05:37 <xarick> okay, I'm stupid! if (index > static_cast<TWaterRegionIndex>(_water_regions.size())) return;
12:05:52 <xarick> uint16_t of a 65536 is 0 🙂
12:06:03 <xarick> no wonder the regions weren't updating
12:06:13 <xarick> and only on a 4096x4096 map
12:10:50 *** kuhnovic has joined #openttd
12:11:09 <truebrain> wait, there is a summoning spell?
12:11:26 <kuhnovic> Nah, just what i'd call a Saturday 😛
12:12:00 <michi_cc[d]> Not something with calling the true name thrice and stuff? 🤣
12:14:20 <xarick> took me 4 days to get to the actual cause
12:14:43 <truebrain> meh; telling CMake to not use PCH on some files doesn't seem to work
12:14:47 <truebrain> owh well, patching it is
12:16:06 <xarick> debug mode on 4096x4096 is painfully slow
12:16:14 <kuhnovic> Overflows are a b*tch. That's also why I tend to avoid unsigned ints, been bitten by those too many times
12:16:46 <_jgr_> Simply making things signed doesn't make overflows go away 😛
12:17:24 <Rubidium> xarick: if you want slow, run that in a s390x emulator :D
12:18:19 <xarick> I'm still noob about pointer/reference stuff, so there might be more into this
12:19:39 <kuhnovic> _jgr_: True, but it at least prevents some annoying bugs. X / Y offsets are always a fun one if you're not careful with signed-ness
12:25:01 <xarick> I have a feeling I'm duplicating regions
12:26:04 <xarick> ie, the pathfinder when visiting neighbours is getting a copy of a region, and not the real one
12:29:01 <xarick> this is what I get for trying to outsmart the original code
12:30:53 <xarick> original code: unique_labels.push_back(labels)
12:31:09 <xarick> my code : unique_labels.push_back(waterregionpatchdescs)
12:32:22 <kuhnovic> Blind guess: you probably have a std::vector<WaterRegionPatchDesc>. That implies a copy when you do push_back, because you store them in the vector _by value_
12:38:21 <kuhnovic> Can anyone give me some hints on how to discard a certain chunk of savegame data? I want old files with the data to load without errors. New data preferably shouldn't store it any longer.
12:43:32 *** locosage has joined #openttd
12:43:32 <locosage> OPTS doesn't have saving, does some loading though
12:44:52 <locosage> may be useful as a reference
12:45:11 <kuhnovic> I will have a look at that one, thanks
12:50:13 <truebrain> kuhnovic: if you just don't define a chunk loader, doesn't it just skip the chunk?
12:50:51 <Rubidium> truebrain: I'm so sorry about this ;( I missed a typo in the #warning (trong -> strong) of 11837
12:51:02 <kuhnovic> Nope, it says that an unknown chunk is encountered while loading
12:51:19 <truebrain> Rubidium: did you actually miss it, or did I introduce it after? 😄
12:52:45 <truebrain> kuhnovic: ah, yes, I see, we do some strict validation
12:53:13 <kuhnovic> Yup, which is good. I just have to create a chunk loader that does nothing and saves nothing.
12:53:48 <truebrain> "create" .. modify, you mean 😛
12:53:54 <locosage> It's meh, I'd like to be able to do custom chunks...
12:54:06 <kuhnovic> Create... because I already threw it away 😛
12:54:59 <truebrain> lucky enough, not saving is easy: just don't define a Save()
12:55:41 <truebrain> although .. CH_READONLY might not work for a table
12:55:46 <truebrain> okay, have fun with this 😛
13:00:47 <kuhnovic> Looks like it doesn't work 😛 arrgh
13:02:41 <truebrain> if you get stuck, let us know; we do need a bit more besides "doesn't work" in that case 😄
13:03:00 <kuhnovic> Yeah I know, I'm not going to bother you guys without trying it myself. I was just venting 😛
13:03:10 <truebrain> that is more than fine; we all do 🙂
13:14:21 <peter1138[d]> Anyone want to go out and clean my bike for me...
13:15:13 <truebrain> do you have any idea how cold it is outside?! 😛
13:15:18 <LordAro> peter1138[d]: just clean it in the house
13:15:25 <andythenorth> peter1138[d]: Put it in the shower?
13:15:53 <peter1138[d]> It's a 62 frame 😮
13:17:40 <truebrain> or otherwise: CUT it in half
13:21:33 <andythenorth> oof. Usually 'reload_newgrfs' is the last item in my console. But sometimes it's 'newgame' 😛
13:21:36 <xarick> kuhnovic: `static std::vector<WaterRegionPatchDesc> unique_labels;`
13:21:36 <xarick> oh, so... I can't do that
13:21:51 <andythenorth> "up arrow, enter", is too reflexive
13:22:06 <andythenorth> much slower testing grfs when I trash the current map by accident
13:23:07 <kuhnovic> xarick: WaterRegionPatchDesc (at least the one that I wrote) was just a sort of identifier object that describes which Water Region Patch it represents. It doesn't really refer back to the original data. You might have changed that
13:23:52 <peter1138[d]> truebrain: But yes... I do, that's why I'm asking 😄
13:24:54 <xarick> ` const WaterRegionPatchDesc &neighbor_patch = GetWaterRegionPatchInfo(neighbor_aqueduct_tile);
13:24:54 <xarick> if (std::find(unique_labels.begin(), unique_labels.end(), neighbor_patch) == unique_labels.end()) {
13:24:54 <xarick> unique_labels.push_back(neighbor_patch);
13:25:36 <xarick> then later... after gathering them all
13:25:42 <xarick> ` /* Call the provided callback function on all accessible water region patches. */
13:25:42 <xarick> for (const WaterRegionPatchDesc &neighbor_patch : unique_labels) {
13:25:42 <xarick> callback(neighbor_patch);
13:25:58 <xarick> maybe this is the one that's wrong?
13:28:47 <xarick> all I wanted to do was to prevent duplicate neighbour nodes entries in the pathfinder
13:29:51 <kuhnovic> Definitely don't take a reference on the first line. GetWaterRegionPatchInfo returns an object by value.
13:30:26 <locosage> andythenorth: you can save them just in case ;)
13:30:41 <truebrain> ``` file INSTALL cannot find
13:30:41 <truebrain> "D:/a/OpenTTD-discord-social/OpenTTD-discord-social/build/discord-social.dll.sig":
13:30:59 <andythenorth> I used to have quite aggressive autosave 🙂
13:31:06 <locosage> on that note, I have a feature request for some way for external program to run `reloadnewgrfs` for live reload
13:31:07 <andythenorth> I wonder if there's a .cfg option for that now
13:31:23 <locosage> easiest way is ofc allow it in multiplayer but that doesn't seem like the best one
13:43:17 <kuhnovic> Alright, I have my chunk loading working again. I'm just wondering if it's safe to change the selected part to CH_READONLY to make sure it doesn't write the chunk in the future. It seems to work, but it feels a bit wrong...
13:46:12 <_jgr_> No, you'd have to change it to be a bitmask value and change the test at the top of SlSaveChunk
13:47:59 <_jgr_> Actually, looking again, I think it might be OK
13:48:48 <_jgr_> The value is not used in the load path
13:49:22 <truebrain> don't we have a way to just load nothing? Do you actually need to load it all, I wonder ..
13:49:49 <kuhnovic> I don't need that data anymore, but I haven't found a good way to just say "ignore this stuff"
13:50:46 <peter1138[d]> If we write the size of a chunk it should be possible to just skip it. If not... a bit harder, but not impossible.
13:50:51 <truebrain> as to CH_READONLY, that should be save. For loading, it uses the type from the savegame, not from the code
13:51:11 <_jgr_> The skipping functionality is already there in ChunkHandler::LoadCheck
13:51:52 <truebrain> `SlTableHeader({}); SlSkipArray();`
13:51:59 <truebrain> that in your `Load` should, in theory, just skip loading it
13:53:53 <kuhnovic> Alright, let me try that
13:58:55 <kuhnovic> Seems to work well, and it's much cleaner 🙂
14:01:20 <xarick> My FindNearestShipDepot is almost ready
14:01:38 <Eddi|zuHause> why am i suddenly in a futurama episode?
14:02:01 <xarick> currently just undoing fixes that are already in PR's
14:04:26 <xarick> I reckon it's a bit more than just Finding Nearest Ship Depot... there are some changes in WaterRegion.cpp
14:09:43 <truebrain> He tried to delete the past 😛 That is not possible 😄
14:11:23 <xarick> guess I have to wait for #11817 + #11750, what will come out of them
14:21:53 <xarick> Step 2 of #11768... can't you just call the pf within that region
14:22:40 <xarick> DistanceManhattan/Square is bad
14:23:00 <xarick> it needs a "DistancePathfinder"
14:47:01 <xarick> nevermind, I see why you don't
14:49:04 <xarick> oh it's not! he started the search from the ship!
15:04:59 <peter1138[d]> "lcm"... such readability 😄
15:05:07 <xarick> yeah, exactly what I was gonna say
15:05:55 <peter1138[d]> Silly standard library.
15:11:07 <peter1138[d]> Well, bike cleaned as much as I dare.
15:11:19 <kuhnovic> I guess it's entirely inline with abs and atan 😛
15:11:40 *** talltyler has joined #openttd
15:11:40 <talltyler> I understand that acronym, or intelligence quickly reveals the answer
15:11:58 <talltyler> Don’t mean to call anybody stupid 😛
15:13:09 <xarick> hmm I can take something from #11768, the hashmaker
15:13:37 <peter1138[d]> I understand it *now* because it's associated with replaceing LeastCommonMultiple 🙂
15:20:09 <peter1138[d]> DPD's chatbot going well then...
15:29:31 <xarick> std::numeric_limits<uint>::max(); is this preferable over UINT_MAX?
15:30:45 <kuhnovic> Yes, more std more better
15:31:26 <peter1138[d]> If it's used a lot, making a constant out of it is useful.
15:40:59 <xarick> still awaiting for some merges
15:42:17 <kuhnovic> This will overflow on large maps in JGRPP, which can be bigger than 4096.
15:42:59 <kuhnovic> And since it won't result in huge memory savings I'd say just leave it int
15:43:36 <xarick> I need to care about it?
15:44:32 <_jgr_> xarick: No, I'll deal with any such things if necessary
15:44:37 <locosage> lcm usually goes along gcd and that's more known acronym
15:44:39 <kuhnovic> Technically not, but I figured it's little effort to have these coordinates / hashes JGR-compatible
15:45:02 <_jgr_> I've already changed various water region related types in my branch
15:49:17 <truebrain> right, that repo now creates signed plugins on release
15:49:25 <truebrain> now to replicate that to Steam / GOG Galaxy ... another time 😛
16:16:34 <xarick> I tried an assert there
16:16:59 <xarick> and it asserts because of intro game
16:18:24 <_glx_> intro game is a normal game
16:18:43 <xarick> there's a PR that fixes that, I think it's 11750
16:19:26 <xarick> it can be turned into assert then
16:21:57 <xarick> The InvalidateWaterRegion calls could be a bit more ... surgical
16:22:24 <xarick> only call if there's changes
16:24:16 <kuhnovic> That would make the invalidation a less lightweight operation. At the moment it's super cheap.
16:26:33 <xarick> I see, possibly during map gen
16:28:55 <Rubidium> xarick: you mean not marking it invalid when it's already invalid?
16:29:50 <peter1138[d]> Not marking it invalid when the the change doesn't actually change connected water.
16:29:59 <xarick> making it a bit similar to what docking tile is doing
16:33:49 <_glx_> xarick: it's easy to miss a change when trying to only mark required ones (docking tiles had many missing invalidations)
16:40:12 <xarick> btw, I still disagree with that CreateRandomPath bit....
16:40:20 <xarick> but that's another matter
16:41:06 <xarick> if the highlevelpathfinder doesn't find a path the at least let the low lvl pathfinder try
16:43:55 <kuhnovic> There's no point. The low level is going to run into the max node limit before you know it.
16:44:30 <kuhnovic> And the high level pathfinder should be able to reach the exact same tiles as the low level one. Granted, that is if there are no bugs in the region update function, and you already found one.
16:44:48 <kuhnovic> But that's no reason to just "let the low level pf have a go at it instead"
16:45:03 <peter1138[d]> Yeah that defeats the point of it 😄
16:45:41 <xarick> it does have a chance to return a trackdir, while the hpf returns a random path
16:47:31 <xarick> i prefer ships to bunch up into a corner
16:47:47 <xarick> and still be lost, not have them wander, as I said earlier
16:48:14 <peter1138[d]> If there's no path that trackdir isn't particularly meaningful.
16:48:36 <xarick> by corner I mean, the best node the lpf found
16:48:51 <xarick> before it couldn't go any further
16:49:00 <peter1138[d]> There is no best node 🙂
16:49:06 <_glx_> the best node has no real meaning if there's no path
16:49:35 <xarick> im sure I'm right this time
16:54:06 <kuhnovic> There would be a "best node" that's closest to the goal. But you wouldn't be able to actually reach your goal, and the ship would still be lost. My idea behind the random path was "if a ship is lost, make it act like it's lost".
17:12:06 <xarick> I had a case yesterday where a town growth blocked passage to a lock. I'd prefer to have the ships bunch up around that place rather than being anywhere else. It's easier in my opinion to identify lost ships that way.
17:12:47 <xarick> sometimes the best node isn't helpful but at least having the ships in a bunch is a visual hint
17:14:10 <peter1138[d]> Try displaying path costs when no path is found.
17:16:52 <xarick> it goes by the lowest estimate cost when there's no path
17:26:34 <kuhnovic> xarick: That's a very single-usecase way of looking at it. You are assuming that there are a whole bunch of ships and that that makes it visible to the user. You are also assuming that the blockage near the goal. This stuff needs generic solutions that make sense.
17:28:56 <Rubidium> xarick: what about a viewport at the bottom of the screen showing the ship is missing? I reckon that works more reliably
17:30:07 *** esselfe has quit IRC (Remote host closed the connection)
17:36:27 <xarick> a compromise then, smaller max_nodes value for lpf when hpf finds no path
17:39:11 <_glx_> if there's no path, there's no path
17:39:28 <_glx_> (unless aquaducts are buggy 😉 )
17:40:31 <Eddi|zuHause> if the pathfinder finds no path, there shouldn't be a chance that there exists a path that it didn't find.
17:42:13 <locosage> from the gameplay sense it's better to have them close to the supposed path even if there is none
17:42:29 <locosage> identifying that supposed path is a different question though...
17:43:22 <locosage> let pf walk on land with some penalty if there is no normal path looks like a reasonable option
17:44:01 *** esselfe has joined #openttd
17:44:51 <Eddi|zuHause> how is that preferable to "just go in the general direction"?
17:45:26 <locosage> it's more likely to be correct
17:45:42 <Eddi|zuHause> but there is no "correct"
17:46:06 <Eddi|zuHause> so why go through all that effort, which we know is wasted?
17:46:12 <locosage> the path player thought they would take
17:46:55 <locosage> basically you don't want your ships running all over the map if some griefer raised a tile
17:50:09 <xarick> cut max nodes by 1/4 or so, but let the lpf do the ship bunch up thingie
17:51:29 <Eddi|zuHause> i'm not convinced.
17:55:02 <locosage> anyway, there are multiple ways to find reasonable route even when there is no valid path
17:55:21 <locosage> reverse pf from destination and find the closes pair of reachable points between two sets would be another
17:57:59 <locosage> Though I'd probably go for pf with relatively low land penalty but from the reachable tiles first pf found. As it's likely faster.
17:59:38 <kuhnovic> You could argue that the estimate represents the remaining "distance over land" part
18:01:38 <kuhnovic> But it's not very precise of course. Then again, how accurate does it have to be. You would want something that somewhat good, it doesn't have to be perfect.
18:03:57 <locosage> idk what your estimate is, I wasn't really taking the whole region thing into account here
18:04:31 <andythenorth> stop the lost ships 😛
18:04:36 <andythenorth> out of context andythenorth
18:04:43 <andythenorth> didn't read all of the log 😛
18:05:00 <peter1138[d]> Send them Rwanda?
18:05:14 <Rubidium> teleport them to their destination
18:05:14 <andythenorth> Ship is lost: due to court case
18:05:28 <andythenorth> ship is lost, permanently
18:09:47 <kuhnovic> Ship has lost its mind
18:23:52 <LordAro> that'd be fun - lost ships get a ufo following them, as if the ship is trying to run away from it
18:38:44 <DorpsGek> - Update: Translations from eints (by translators)
18:54:47 <talltyler> Sorry Rubidium, I created a merge conflict for myself and had to fix it 🙂
18:57:39 <xarick> who needs a savegame with 64k depots?
19:53:12 <peter1138[d]> Well... I don't think the game should draw nothing either. It's masked to show that it's unavailable. Drawing nothing would be very odd.
19:57:13 <talltyler> Could we hide the whole button? Or would that be worse?
20:01:20 <truebrain> lolz, our nightly failed .. on something I tried to prevent .. but clearly failed 😄
20:01:28 <truebrain> stupid Linux Legacy 😛
20:02:44 <peter1138[d]> Hmm, CI target for Linux Legacy possible?
20:03:18 <peter1138[d]> "Upload (Steam)" getting a green tick seems a bit awkward.
20:04:06 <truebrain> peter1138[d]: it is; as it doesn't need Linux Legacy, it continued
20:04:31 <truebrain> I regret that I went for the legacy route
20:06:06 <truebrain> hmm .. I was about to fix it, but also .. do I actually care Steam gets a new version while other places don't ... I guess ...
20:06:10 <truebrain> but fixing it is also meh 😛
20:06:10 <peter1138[d]> talltyler: Probably worse tbh. I've split those posts off to a new thread.
20:07:03 <peter1138[d]> One "build complete on all targets" job, then depend on that. Or I don't know how it's arranged.
20:07:17 <truebrain> yeah, was trying something like that now
20:11:45 <truebrain> let's test if it actually works 😛
20:14:26 <truebrain> hmm .. on Linux, I do an `fread(..., filesize, 1, ..)` , and that returns 1
20:14:29 <truebrain> on Windows, it returns 0
20:14:56 <talltyler> peter1138[d]: The last two commits in #10700 are my solution to the vehicle aging bug in NotDaylength... thoughts?
20:15:33 <truebrain> it can only read 497 of the 510 bytes the file is big
20:16:15 <peter1138[d]> At least... I think.
20:17:08 <truebrain> you are not alone; it is silly 😛
20:17:56 <_glx_> yeah looks better like that
20:22:29 <truebrain> okay, it now also works on Windows .. now I need someone to test it on MacOS 😛
20:22:50 <peter1138[d]> talltyler: Hmm, now it ages all vehicles on the same tick. Might have quite a penalty
20:23:05 <talltyler> Yeah, that's my main concern
20:23:49 <talltyler> I'm not sure how to test in a meaningful way
20:24:55 <talltyler> Where would I find a copy?
20:25:02 <peter1138[d]> (Probably not, the business of that swamps everything)
20:29:32 <_glx_> it's always possible to spread in more ticks
20:30:23 <peter1138[d]> The issue is knowing how many ticks to spread, and how many ticks to spread if the daylength setting changes.
20:30:38 <peter1138[d]> Or whatever the setting is called 😄
20:31:46 <peter1138[d]> The first part isn't too bad, but making sure you don't miss ticks or add multiple ticks...
20:31:54 <truebrain> ugh, I forgot how much of a mess we made of the memory management in the network stack .. every time I look at it I am like: yeah, this really needs a sit-down and rewrite, as this is really bad 😛
20:32:06 <talltyler> I could spread it over economy ticks, but I’m not entirely sure how to do that in a not-ugly way
20:32:17 <talltyler> (Because economy ticks never change rate)
20:32:36 <peter1138[d]> One thing that might help diagnosing that is to store the day of the last calendar-day-tick for a vehicle. Then at least we can see if anything is missed or done twice?
20:35:05 <peter1138[d]> Ticking on economy ticks is probably right, but needs special handling for very slow time.
20:35:17 <truebrain> is aging a property of economy or of calendar?
20:35:39 <talltyler> (It used to be economy but Peter changed my mind)
20:35:57 <truebrain> for me it is a cointoss; one can argue both 😛
20:36:03 <talltyler> Service interval is still economy
20:36:31 <peter1138[d]> Yes, that's fine 😄
20:36:57 <truebrain> and `OnNewDay` is economy based?
20:37:08 <talltyler> truebrain: It would be much easier to make it economy and leave it in OnNewDay 😛
20:37:09 <peter1138[d]> Although I suspect model-railwayers will want that to be calendar-based too.
20:37:37 <talltyler> Model railway-ers just turn off breakdowns
20:38:21 <truebrain> so you want an OnNewCalendarDay, basically?
20:38:42 <xarick> I got a small little inconvenience to solve with the high level pathfinder and find nearest ship depot when the starting region is also the destination region
20:38:45 <talltyler> Yeah, that’s basically what the timer is
20:38:47 <peter1138[d]> There's no problem doing that, and that's what the latest patch does.
20:38:56 <truebrain> no, the timer runs every day
20:39:04 <truebrain> OnNewDay does not run all vehicles all the time on each new day
20:39:06 <xarick> but the hpf doesn't know it yet 😦
20:39:15 <truebrain> so they are not the same
20:39:20 <truebrain> but so why not make a OnNewCalendarDay?
20:39:43 <peter1138[d]> Yes we know they are not the same, that's what we're splitting hairs over 🙂
20:39:48 <truebrain> you can't use the IntervalTimer btw; but similar code to OnNewDay should be easy
20:40:23 <xarick> it's not that it doesn't work, but it's running the pf and it goes around the origin for nothing
20:40:35 <peter1138[d]> Hmm, is there is calendar ticks in a calendar day?
20:42:21 <talltyler> Yes, TimerGameCalendar::date_fract still goes to 74 before moving to the next day
20:42:58 <talltyler> The problem is that when we slow down time, date_fract is updated less than once per tick, so we'd age the same vehicle repeatedly unless we noticed and skipped it
20:43:07 <peter1138[d]> Hmm, so it could work off that.
20:43:38 <truebrain> talltyler: huh? What my suggestion is, to hook into "date_fract changed"
20:43:51 <peter1138[d]> Well, if it's a timer event like you've done, but on new tick instead of new day...?
20:43:53 <truebrain> and make a new OnNewDay that is called distributed like the current one based on that change
20:44:04 <truebrain> there is no "new tick" timer, for performance reasons 🙂
20:44:35 <talltyler> truebrain: Ah, instead of the StateGameLoop() which currently calls it
20:45:13 <truebrain> hmm, in that PR you updated, ND doesn't exist yet I see 😛
20:45:22 <truebrain> need to know how you actually slow down time 😄
20:46:16 <truebrain> ah, okay: I would make Elapsed return a boolean
20:46:22 <truebrain> to indicate whether a tick happened or not
20:46:36 <_glx_> nice, rebasing doesn't dismiss
20:46:42 <truebrain> next in the StateGameLoop you can see that, and call OnVehicleTick variant for calendar
20:47:02 <truebrain> which calls OnNewDay variant for calendar, based on the tick
20:47:44 <talltyler> Oh, that's clever 🙂
20:47:54 <truebrain> owh, and totally unrelated: I do understand it right you cannot go quicker than the current tick-rate, the calendar?
20:47:57 <truebrain> it can only go slower?
20:48:36 <talltyler> Correct, the fastest theoretical speed is one tick per day
20:48:40 <truebrain> hmm, no, that commit is a bit odd ..
20:48:45 <truebrain> date_fract increases, even when slowed down
20:48:48 <talltyler> But you can't reach that since the minimum setting is 1 minute per year
20:48:58 <truebrain> I would not do that, honestly
20:49:02 <truebrain> I would add a new variable
20:49:17 <truebrain> and I would leave date_fract to be 74 in a day
20:49:24 <truebrain> as now that becomes variable
20:49:28 <truebrain> with .. possible consequences?
20:50:45 <talltyler> How do I track if the date_fract should update?
20:51:03 <truebrain> what I would have done, but I might be missing parts of this puzzle
20:51:08 <truebrain> is add a new variable in Calendar
20:51:21 <truebrain> and if that hits what-ever-the-value-is, increase date-fract
20:51:37 <truebrain> you can use date-fract, to get a bit more fine-grained control
20:51:53 <truebrain> but I would have only updated date-fract when 1/74th of a calendar day passed
20:51:57 <truebrain> that way, this also becomes really easy
20:52:34 <talltyler> So like a sub_date_fract?
20:52:46 <talltyler> It sounds more confusing to me, personally 🙂
20:53:17 <talltyler> Unless the idea is to avoid people using date_fract for stuff like spreading out ticks and shooting themselves the foot 😛
20:53:35 <truebrain> take for example NewGRF variable 09
20:53:39 <_glx_> we already use date_fract to spread
20:53:42 <truebrain> `TimerGameCalendar::date_fract * 885`
20:53:47 <peter1138[d]> Oh, so it isn't 74 ?
20:53:54 <talltyler> For spreading, we use economy date fract
20:53:57 <truebrain> in your current solution, this scales with the dilation
20:54:01 <talltyler> Which is always 74 game ticks
20:54:08 <truebrain> so NewGRFs see this value changing to VERY high numbers in VERY slow games
20:54:14 <truebrain> which might be totally unexpected
20:54:28 <truebrain> just one example of more places I expect to find, if you no longer have _date_fract rollover at 74
20:54:53 <truebrain> so personally, I would not touch the concepts of time like that
20:55:02 <truebrain> dilation just prevents time from passing, including the fract
20:55:07 <peter1138[d]> Is this the case or not? Confused now.
20:55:31 <truebrain> his commit told a different story 😛
20:55:50 <talltyler> It’s hard to keep track of the whole thing sometimes
20:56:13 <truebrain> anyway, a counter is kinda tricky btw, as I assume you want to allow for 10% slowdowns, and not in steps of 100%?
20:56:16 <Eddi|zuHause> if it were easy it would have been done 15 years ago :p
20:56:44 <truebrain> so sometimes you want to increase date-fract every tick, and sometimes every other tick
20:56:53 <truebrain> so think about it for a bit how you want to do that
20:57:04 <truebrain> but if you did that, having Elapsed return true when date-fract increased is simple
20:57:10 <truebrain> and the rest of this problem resolves itself from there
20:57:30 <talltyler> Yeah, that seems to be the way to go
20:57:41 <truebrain> also keeps things more the same between timers
20:57:43 <talltyler> And it avoids silly GRF API mostly 🙂
20:58:25 <truebrain> well, to name other issues ... UpdateOrderDest also uses `TimerGameCalendar::date_fract` to spread out things over vehicles
20:58:42 <truebrain> which might be a bug, and should have been Economy?
20:59:13 <_glx_> might be a bug, it's a recent change for orders
20:59:48 <truebrain> hmm, now I look over it .. I think most `TimerGameCalendar::date_fract` should be economy 🙂 Might be worth a search, once you figured this issue out 😄
21:00:01 <talltyler> Yes, most should be
21:00:08 <talltyler> I will do a thorough search
21:00:10 <truebrain> desync stuff is also now on Calendar .. I think it should be Economy 😄
21:01:07 <talltyler> I did a thorough inventory months ago but lots has changed since then 🙂
21:01:13 <truebrain> okay, so the NewGRF entry is the only legit one 😄 Okay, so that isn't as bad as I expected 😛
21:01:23 <talltyler> (And lots of rebases with conflicts may have lost things)
21:01:41 <xarick> my fault, I guess. I'm not familiar with the game having two timers
21:01:45 <truebrain> it is okay; it is a complex set of changes over many weeks
21:01:57 <truebrain> so I expect to find issues over your rebases 😄
21:02:01 <_glx_> no it was fine on your side xarick
21:02:03 <talltyler> xarick: It doesn’t yet 😉
21:02:58 <_glx_> the change in order was my suggestion 😉
21:04:20 <truebrain> talltyler: bit further look into it, you can skip `CallVehicles` etc and just make a copy of `RunVehicleDayProc`, but based on Calendar. `RunVehicleCalendarDayProc`, and rename the other one? 😄 Should be straightforward from there
21:05:28 <peter1138[d]> Heh, it's normally spelled connector.
21:05:44 <truebrain> we had such long conversations about connector vs connecter
21:06:11 <truebrain> no, nothing to do with Dutch, sadly
21:06:14 <truebrain> Connecter is British
21:06:16 <truebrain> Connector is American
21:06:28 <truebrain> just British people stopped using it
21:07:01 <truebrain> not the first time someone mentions it, and won't be the last either 😛 At least our codebase is mostly consistent here 😛
21:07:07 <_glx_> it's as sad as constant use of "digital" in french
21:07:44 <_glx_> which is completely wrong
21:10:57 <peter1138[d]> It's impossible find definitions these days as it's all LLM "AI" bullshit.
21:11:19 <truebrain> or less commonly connecter
21:11:27 <truebrain> not that hard to find definitions 😄
21:11:45 <truebrain> it fell out of grace in British English for sure
21:11:47 <peter1138[d]> But the only dictionary reference I can find says -er is an American form :p
21:12:00 <peter1138[d]> yes, definitions, but none that say if it's british or american.
21:12:16 <peter1138[d]> And that's an American dictionary so is by definition wrong anyway.
21:13:18 <peter1138[d]> Anyway, totally irrelevant.
21:14:14 <truebrain> sorry Rubidium, but you stepped in a bit of a waspsnest with that PR 😛 I looked at it one too many times to know it is really odd 😦
21:14:38 <truebrain> and I made it so much worse with the Game Coordinator connection
21:16:14 <truebrain> code from when were babies, and didn't actually know how to write C++ 😛
21:16:18 <truebrain> I still don't, but that is not the point 😄
21:18:34 <Rubidium> CTRL+A DELETE.... why did I first read that as CTRL+ALT+DELETE?
21:18:52 <truebrain> your reading might be safer to execute 😛
21:19:34 <_glx_> I did too, then I re-read slowly
21:22:26 <truebrain> ugh, trying to understand the code again, and failing 😛 When does a Connecter normally clean up ..
21:22:50 <_glx_> it was already hard to follow when you wrote it 🙂
21:23:21 <truebrain> owh, right, when it is connected, CheckCallbacks removes it
21:25:35 <truebrain> I guess `KillAll` should call `OnFailure` first, or something
21:27:06 <truebrain> as that causes `game_connecter` (and friends) to set their pointer to nullptr, which does result in a dtor call 😛 But boy .. this code .. 😄
21:28:06 <peter1138[d]> Move the connection killing code to a method outside the destructor, Make KillAll (and the destructor) call that method.
21:28:47 <peter1138[d]> Probably doesn't solve anything
21:31:56 <_zephyris> Anyone know a good NewGRF for testing vehicle variants with the subtypes tree that looks like the settings tree?
21:32:15 <peter1138[d]> andythenorth has one.
21:32:24 <peter1138[d]> Iron Horse, not sure if the bananas version has variants yet.
21:33:27 <Rubidium> truebrain: TCPConnecter::KillAll gets called only from NetworkClose after all the socket handlers have already been closed
21:34:09 <Rubidium> now, that's how you structured the code :D
21:34:12 <truebrain> this flow is just incredibly .... awkward 😛
21:34:31 <Rubidium> it's async at its finest...
21:34:32 <truebrain> yeah ... because I didn't want to rewrite `my_client` 😛
21:34:46 <truebrain> as in the core of all issues ... it all starts with that weird `my_client` we have
21:35:14 <truebrain> but a lot more things are possible now than they were, so that is good
21:35:35 <truebrain> does a static non-POD class member need initialization?
21:35:38 <truebrain> I can never remember 😦
21:35:49 <peter1138[d]> Only if it's an array 😮
21:35:56 <truebrain> which is a POD in hiding 😛
21:36:29 <peter1138[d]> Added bonus: it worked in all my testing and only failed on one CI target...
21:36:31 <truebrain> Rubidium: did we have a way that nobody was allowed to call the ctor except for `Create`?
21:37:01 <peter1138[d]> I recall a similar issue with widget factory...
21:37:10 <truebrain> yeah, I do too, just not the answer 😛
21:37:59 <peter1138[d]> You can friend std::make_shared as a function on some platforms but not all. So...
21:38:11 <truebrain> ah, that was the weirdness
21:38:27 <peter1138[d]> Maybe c++20 has a fix though
21:39:16 <truebrain> let me test 11848 first ... as I think it fixes it, but .... 😛
21:42:24 <truebrain> ~160 `free()` calls left in our code-base
21:44:39 <talltyler> There's vehicle aging, now to rebase all the PRs stacked on top of this, and change how we update TimerGameCalendar::date_fract 🙂
21:45:22 <LordAro> truebrain: as few as that :o
21:45:23 <peter1138[d]> I probably have patches for some of those frees.
21:45:39 <truebrain> talltyler: You now age all vehicles; is that intended?
21:45:50 <truebrain> also disaster vehicles, I guess
21:46:03 <truebrain> it also misses checks like `if (!this->IsNormalAircraft()) return;`
21:46:17 <talltyler> That step in the middle was important I guess 🙂
21:46:19 <LordAro> how many [MC]allocTs?
21:46:39 <truebrain> 347 ` new ` .. which could be argued, should either be unique-ptr or shared-ptr
21:46:44 <Rubidium> truebrain: if you don't use Create then your TCPConnecter will not be put into the vector, and *nothing* will ever happen to your connecter. So you'll quickly find out when testing it, as it simply would not work. I hope that's enough
21:46:54 <truebrain> LordAro: ~100 of those
21:47:11 <truebrain> Rubidium: depends .. did you test all the parts of our networkstack with your PR? 😄
21:47:20 <truebrain> I rather have a compiler telling me: NO, when doing refactors 😉
21:47:28 <truebrain> I mean, you are the one who wants unittests! 😄
21:48:13 <truebrain> but I did some grepping to see if there was any other creator of TCPConnecter, and I couldn't find one anymore either; so I guess that will have to do 🙂
21:48:44 <truebrain> just one of those things that remains annoying .. you can't template a ctor, and you can't hide the ctor from normal use .. such a pita 😛
21:48:45 <Rubidium> yeah, I looked at all sub classes of TCPConnector to find where they were using new
21:54:00 <truebrain> peter1138[d]: nope, not fixed for C++20
21:54:02 <truebrain> it does work with unique_ptr
21:56:38 <truebrain> haha, there is a trick, that is even on cppreference
21:58:23 <truebrain> so we could do that 😛
21:59:51 <peter1138[d]> Seems it creates an instance and then copies it to unique_ptr?
22:00:07 <truebrain> not sure what you mean?
22:00:23 <truebrain> this adds an empty struct that is private to the ctor parameters
22:00:32 <truebrain> in result, nobody can ever use the ctor, as they don't have access to the struct
22:00:38 <truebrain> the struct does nothing, as it is empty, and will be optimized out
22:01:10 <truebrain> "nobody" -> "anyone from outside the class"
22:01:22 <truebrain> it is a pretty nifty way to deny access to the ctor 🙂
22:03:05 <truebrain> I guess having such a struct to deny access to the ctor is as weird as having a friend to a ` make_shared` 🙂
22:06:51 <truebrain> MacOS builds have this lovely randomness of how long they take to complete .. sometimes 6 minutes, sometimes 20 minutes ..
22:09:50 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:12:15 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:15:58 <truebrain> same trick via templating
22:16:26 <peter1138[d]> Oh right, that trick.
22:17:06 <truebrain> benefit of this trick, you only need to make a helper class once
22:17:13 <truebrain> the rest of your classes are more readable
22:18:13 <talltyler> Making it conditional based on if we increment TimerGameCalendar::date_fract happens a couple PRs down the line 🙂
22:18:13 <truebrain> that is exactly what I meant 😄
22:18:26 <talltyler> Perfect, time to rebase and do the second part 🙂
22:18:38 <truebrain> this way, you don't change anything on the behaviour in normal games
22:18:57 <truebrain> peter1138[d]: at least there are options 🙂
22:21:03 <truebrain> peter1138[d]: honestly, I wouldn't mind as much, as we would have a solution like that with `: public ForceUnique<>` and `: public ForceShared<>` .. it does avoid people doing weird shit 😛
22:21:25 <truebrain> lollzzzzz ... so I did this fake `Upload` step with `pass` ....
22:21:29 <truebrain> it isn't Python .. it is bash ...
22:21:33 <truebrain> `pass` does ... something else
22:21:55 <truebrain> and NEITHER of you two saw that! 😛
22:22:15 <truebrain> right, started another test .... another 30+ minutes of waiting 🙂
22:27:00 <truebrain> LordAro: that is a rather cryptic comment 😛
22:28:53 <_glx_> good my approval was dismissed 🙂
22:29:04 <truebrain> it should be good now; but test is still running 🙂
22:29:17 <truebrain> just happy I tested; and not blindly was like: this should be fine!!! 😛
22:31:35 <_glx_> hmm wondering if disabling the upload step for forks (if possible) would prevent all upload failures
22:31:58 <_glx_> as they now depend on this step
22:32:11 <truebrain> feel free to experiment
22:32:23 <truebrain> the repository name would be a way to do that
22:32:32 <truebrain> not sure if there is another indicator whether it is a fork or not
22:32:43 <_glx_> yeah that's the not easy part
22:33:10 <truebrain> skipping the signing steps would also be nice; now they trigger an error but are skipped
22:50:38 <truebrain> _glx_: I also would really like to add Upload to GitHub Releases .. I have that code for the social plugins. But that should trigger also on forks.
22:52:45 <_glx_> and remove the auto source from github
22:52:55 <truebrain> yeah, means people can make a release on their fork (from a branch), and share the binaries, for testing etc
22:53:11 <truebrain> after that, I might remove the branch-building from upstream
22:54:40 <_glx_> before/after or the opposite ?
22:54:46 <peter1138[d]> Before/after, yes.
22:54:55 <truebrain> before/after what, is the question 😛
22:55:21 <_glx_> what did you change to video output ?
22:55:46 <peter1138[d]> Train ticks looks worse but the total is very similar. So it feels like something isn't being counted...
22:56:09 <truebrain> yeah, it is a bit odd, that everything added up doesn't add up 😄
22:56:19 <peter1138[d]> _glx_: sdl v1.2 vs sdl v2 with hardware acceleration
22:56:51 <peter1138[d]> I build with sdl v1.2 otherwise I can't debug properly... the mouse stays captured and hidden with sdl v2.
22:59:15 <peter1138[d]> I have a map of vehicles of each type, so instead of using PerformanceAccumulator for each vehicle, it can use PerformanceMeasurer across each type.
22:59:42 <peter1138[d]> And I use a map so that I get correct consistent insertion order for free.
22:59:54 <peter1138[d]> But probably not the best structure.
23:00:11 <peter1138[d]> Seems to help RVs though.
23:01:46 <xarick> do you want my savegame with... 1 million vehicles? though they're all stopped inside depots
23:01:57 <peter1138[d]> There's a few things in Train::Tick that are not counted. With the number of wagons there are, pretty sure that can add up quickly.
23:02:35 <peter1138[d]> So although 10055 improved performance, it also misreports performance.
23:03:03 <peter1138[d]> The misreporting is less problematic than the performance gain 🙂
23:03:16 <truebrain> remove performance accumulator? 😛
23:03:27 <peter1138[d]> Also, one reason this doesn't improve much for me is because I'm running Linux now. This was mostly an issue on Windows.
23:03:46 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:03:53 <truebrain> okay, something is still smelly with my CI PR ...
23:03:58 <truebrain> now it stops after the Upload job
23:04:00 <truebrain> that was not what I wrote
23:04:08 <peter1138[d]> Hmm, I need to tick DisasterVehicle and EffectVehicle as well.
23:04:35 <truebrain> I am not really sure why it skipped the job ..
23:06:24 <talltyler> Thinking aloud, if the calendar is running faster than usual, we need to advance the date when date_fract is less than 74. Is that permissible or should we disallow faster than usual speeds?
23:06:58 <truebrain> didn't you say earlier that below 100% was not possible?
23:07:04 <truebrain> as your current PR doesn't allow for it 😛
23:07:14 <truebrain> (or above 100%, pick a reference frame)
23:07:15 <talltyler> A day cannot be faster than one tick
23:07:20 <talltyler> It can be faster than 74
23:07:31 <_glx_> truebrain: there's no reason for it to skip
23:07:47 <talltyler> If my math is right, one minute per year is 6 ticks per day
23:08:06 <truebrain> ah, like that, yeah, okay, fair enough
23:08:14 <truebrain> I misunderstood your answer earlier in that case
23:08:29 <talltyler> I don't really see a strong usecase for faster than usual calendar, but have learned not to tell players how to play 🙂
23:08:32 <truebrain> anyway, for faster than normal, what I would advise, is to loop over `Elapsed` more than once
23:08:56 <truebrain> but you get in a very weird place, when you start trying to implement this cleanly
23:09:09 <truebrain> so maybe start off with not allowing faster than 100%
23:09:46 <talltyler> I would happily do that (set the minimum value of `Minutes per year` to 12) but I'm using 0 as a special value to freeze time entirely...
23:09:48 <peter1138[d]> The line-drawing algorithm has a clue what to do (and a bug...)
23:10:00 <truebrain> you can still keep 0 🙂
23:10:27 <talltyler> Ah, so clamp with a callback instead of using a minimum value in the settings.ini file
23:10:58 <peter1138[d]> Hmm, ticking effect vehicles blows up. :/
23:11:03 <truebrain> I would do, everything between 1 and 11 becomes 0
23:11:18 <talltyler> Yeah, that should be easy todo
23:11:20 <peter1138[d]> I think that means my iterator is being modified. Damn it.
23:11:25 <truebrain> just going back from 1 would be annoying
23:11:35 <truebrain> if new < old and below 12 -> 0
23:11:39 <truebrain> if new > old and below 12 -> 12
23:12:25 <talltyler> Does it track the previous value?
23:12:39 <talltyler> As a pre_cb maybe it would work
23:12:48 <talltyler> Dinnertime, I will think about that later
23:12:56 <truebrain> _glx_: maybe because an earlier step skipped?
23:15:00 <_glx_> I guess you need to copy paste line 102
23:15:44 <truebrain> once again, happy we test this first 😄
23:15:46 <_glx_> seems we worked around the issue earlier
23:16:34 <truebrain> no, the other one was sensible
23:16:37 <_glx_> as it means transfering all the deps
23:16:43 <truebrain> it cannot know if you want a skipped step to be okay or not
23:16:54 <truebrain> but that the dependency on that dependency, which fully succeeded, still needs it
23:17:20 <_glx_> yeah line 102 makes sense
23:17:38 <truebrain> but okay ... made the jobs a bit smaller, for easier testing ..
23:17:49 <truebrain> done with waiting 40+ minutes to see if I made a mistake
23:18:00 <_glx_> the unexpected skip don't
23:18:34 <truebrain> okay, now it at least continues
23:19:23 <truebrain> and forgive me sarcastic comment
23:19:35 <truebrain> but I couldn't resist adding that in there 😛
23:19:41 <truebrain> right, now it is tested and working 🙂
23:19:49 <truebrain> tomorrow it will have its actual test 😛
23:20:23 <_glx_> we indeed use `always()` in 'unpload'
23:20:43 <truebrain> or `alsways`, as he spelled it
23:22:32 <_glx_> anyway it's annoying to need always in all descendant
23:23:26 <_glx_> especially when descendant don't directly depend on possibly skipped
23:27:24 <_glx_> hehe at least it didn't skip in your last test run 🙂
23:27:50 <truebrain> Yeah, current PR works as far as I can test it atm 🙂
23:30:49 <_glx_> release workflow is the worst to test 🙂
23:31:56 <xarick> that break at line 386 is possibly unreached
23:32:12 <xarick> need to take a look at this
23:32:25 <truebrain> Yup. But removing workflow dispatch, and uploading to GitHub will make it a bit easier as you can then test properly with fork releases .. I think 🙂
23:37:35 <truebrain> I received 195 mails from GitHub today
23:39:57 <xarick> meh... i made a mistake
23:42:53 <xarick> how do i push the contents from my testing branch into the other branch, the one that got closed, and how to reopen now?
23:43:14 <_glx_> you pushed an empty branch
23:43:31 <xarick> was going to add to it
23:43:41 <_glx_> cherry pick the commits
23:43:54 <xarick> but... failed, and git picked it up and decided to close it
23:47:21 <xarick> well, it remained close
23:49:17 <xarick> just something you have to play around
23:49:25 <xarick> if you're willing to test it
23:51:33 <peter1138[d]> As it doesn't compile, no 😉
23:51:52 <peter1138[d]> pair is one of those occasions where you should use auto.
23:55:15 <peter1138[d]> Hmm, probably possible to use these lists where we use vehicle-type specificTrain::Iterate()
continue to next day ⏵
