IRC logs for #openttd on OFTC at 2024-01-08
โด go to previous day
00:00:38 <tabytac> i think one of my games is 25, but it wasnt on newest jgrpp
00:00:52 <reldred> This is depressing though. I thought more people would be making those tropics coasts greener.
00:01:51 <tabytac> reldred: that might just be most people dont play with that climate, and so dont change the setting. its only 13%
00:02:07 <emperorjake> I didn't even know about that one
00:02:26 <reldred> emperorjake: I added soooo many worldgen settings for tropic
00:03:23 <reldred> JGR had to help me with a few of them though. Those coasts were a bit tricky. And I'm not happy with the circular pattern it uses for tropics around rivers either, at high values it becomes very very square.
00:11:22 <tabytac> this hardware survey is very interesting
00:11:24 <_jgr_> `CircularTileSearch` is not actually a circle shape
00:11:37 <_jgr_> You'll need to add some extra logic if you want an actual circle
00:11:39 <tabytac> would be interesting to compare that to the steam hadware survey
00:13:27 <reldred> _jgr_: Yeah, figured as much. It doesn't look bad at low values but at high values it gets rather square.
00:14:39 <reldred> Anyways, I was dreaming of verticality and landscaping last night. Got some ideas I want to play with some more at some point.
00:15:46 <reldred> "explain your reasoning for X" "it was revealed to me in a dream"
00:17:51 <reldred> thats a lol bug report
00:24:41 <emperorjake> what's the deal with mars canal graphics? They work fine
00:24:51 <truebrain> Despite the fact creating a bug makes you press a button first, it is still very confusing to people. I wonder if we can improve that.
00:25:41 <reldred> emperorjake: I think they meant rivers, given they quote temperate grass.
00:26:21 <emperorjake> Ah, makes sense. Someone would have to draw them then
00:28:48 <truebrain> I was trying to get below 200, but it is hard work ๐
00:29:33 <truebrain> At least got it to 200!
00:30:04 <truebrain> Now if people can stop opening feature requests on our bugtracker, that would be appreciated ๐
00:30:24 <reldred> Well, #5713 can be closed by implementing the new boat pathfinder
00:31:10 <LordAro> 200! is a really big number
00:31:12 <peter1138[d]> Oh that was obvious. Instead of complicated logic to update the label map, just rebuild it every time either a bitnum or a label is changed.
00:31:27 <truebrain> LordAro: Go to sleep ๐
00:32:04 <reldred> Our ticketing system at work had nearly 200 tickets in it when I started, now it's like, no more than 50? and a bunch of those are just maintenance tickets that turnover every month.
00:32:37 <truebrain> 0130 here ... need to be up again in 6 ..
00:32:50 <LordAro> our dev bug tracker has over 3000 open items
00:33:10 <LordAro> the IT task/ticket tracker is probably about 50
00:33:18 <truebrain> If nobody touched a ticket in over a year, it was not really important ๐
00:33:35 <reldred> Auto-close anything older than three days ๐
00:39:05 <peter1138[d]> 3am is the best time to make PRs.
00:43:53 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
00:46:40 <peter1138[d]> Is it possible for a newgrf to define some cargo properties and then... get disabled with GRFInhibit?
00:49:19 <reldred> I think that's what happens when ECS has the sads about how you've loaded it?
00:51:38 <reldred> kinda why I never got into ecs
00:54:04 <peter1138[d]> Cargos are a bit weird, they are loaded at the reservation stage, to ensure they are available for other features later.
01:07:35 <peter1138[d]> I guess "load the cargo first" could've been
01:17:28 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:49:16 *** Wormnest has joined #openttd
01:59:11 <reldred> woooo baby, mikrotik added mvrp support, my life has become significantly easier now lmao
01:59:48 <reldred> well, when it hits a mainline release.
02:08:22 <peter1138[d]> Used to use Cisco's VTP back in the day.
02:10:07 <reldred> Yeah, we run all our DC stuff on mikrotik, I don't mind it, our setup is only small though.
02:10:51 <reldred> Just did a layer 2/mlag based leaf and spine setup for a customer, and preparing to rejig our DC setup to use that rather than the massive mess of rstp
02:11:25 <reldred> so looking forward to mrvp handling all the vlan stuff across all the north south bonds
02:13:18 <peter1138[d]> Cheap and cheerful. I also use Mikrotik but the network is tiny compared to my old job. (And even that was small, but spread out a bit)
02:16:10 <peter1138[d]> I still have issues with LACP and stateful firewall rules... pom te pom.
02:26:18 <reldred> Yeah, LACP/MLAG has been behaving for me on 7.12
02:27:10 <reldred> if we were doing higher port densities we'd use another vendor but yeah, before I'd come on board they'd had mikrotik in their DC for 5+ years with only one failure, which wouldn't have even been an issue if they designed it properly to begin with
02:28:06 <reldred> I went live in march with a new stack with brand new CCR514's and CRS518's running 7.8
02:33:52 <peter1138[d]> I have hEX 750gr3 at home, so not much call for LACP.
02:34:40 <peter1138[d]> I do have bonding on my home server but it's just active-backup as LACP would need to go via the router's CPU.
02:35:37 <peter1138[d]> Hmm, so I need a really old cargo NewGRF ๐
02:42:57 <reldred> Yeah Iโm not super familiar with those little routers that donโt have switch chips
02:43:28 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
02:43:31 <peter1138[d]> Anything the switch can't do is offloaded to CPU, with resultant performance drop.
02:43:46 <reldred> I love that the CCR514 has the full marvel prestera chip that the CRS518 has. Soooooo much flexibility.
02:45:30 <reldred> Pretty much built my entire network as layered on the layer 3 functions as virtual interfaces. The processor on the CCR514 is a monster as well so it has no problems with it.
02:52:39 <reldred> Goddamn apple autocorrect
03:00:10 *** Wormnest has joined #openttd
03:38:26 *** Wormnest has quit IRC (Quit: Leaving)
03:53:51 *** debdog has quit IRC (Ping timeout: 480 seconds)
05:57:51 *** D-HUND is now known as debdog
06:14:30 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:31:33 *** tokai|noir has joined #openttd
07:31:33 *** ChanServ sets mode: +v tokai|noir
07:38:26 *** tokai has quit IRC (Ping timeout: 480 seconds)
09:35:57 <orudge> truebrain: nightly notarization should be fixed now (accepted the new agreement). Haven't looked into the other notarization thing yet, got a couple of other things to catch up on first, but we can figure it out soon hopefully.
09:37:13 <truebrain> Nice! Will be home in like 8 hours, so no rush ๐
09:41:56 <peter1138[d]> Hmm, `assert(i < array_size); array[i]...` vs `array.at(i)...`
09:43:52 <peter1138[d]> > `std::out_of_range` if `pos >= size()`.
10:00:21 <peter1138[d]> Ah, clangd extension helpfully adds missing includes... and that then causes interdependency issues ๐
10:15:14 <xarick> updated over 1700 commits
10:16:30 <xarick> i dont think kuhnovic did add that component on his code
10:31:49 <xarick> now that 11548 is also merged... 10544 is in a more fair light
11:06:44 <xarick> the diff shows so many unneeded changes
11:07:02 <xarick> adding a dot, or a capital letter just to inflate the diff size
11:08:18 <xarick> when it's me, all hell let loose, when it's someone else, it's approved
11:11:01 <LordAro> there's a certain allowance made when you're essentially rewriting the whole file
11:11:09 <LordAro> and it is a strict improvement
11:16:40 <xarick> since it's more likely that his PR is merged first, I'm gonna have to deal with conflicts with 10543 after
11:17:32 <xarick> i wish mine was merged first, and make kuhnovic deal with them, he seems more fit for the job
11:19:14 <xarick> I'm gonna have to learn how his code works to adapt it and might do a bad job at it
11:20:46 <xarick> the other way around, it was me just mimicking the original yapf which was then updated to region based by Kuhnovic, oh well...
11:21:48 <peter1138[d]> Me: "We need to record 9 different nut types" Them: "Can't we just say 'nuts', that's too much work" Me: "Not in law, no."
11:24:12 <peter1138[d]> (Why yes, yes I am just a software developer...)
11:31:52 <locosage> talltyler: sure, can it wait a few days though? didn't even have time to catch up to the chat yet
11:40:09 <Eddi|zuHause> xarick: in programming, it's generally helpful to actually understand the code you're changing
11:41:06 <xarick> I'm trying to read what he does
11:55:39 <xarick> okay, i made it that far as making it build openttd
11:55:54 <xarick> but it's not using the region based stuff yet
11:59:21 <xarick> not sure if this is something I should be worried about
12:00:29 <_glx_> You should, it can be similar to squirrel's "too many locals"
12:01:54 <xarick> ChooseShipTrack and CheckShipReverse have similar warnings
12:01:58 <xarick> and I didn't touch them
12:03:11 <_glx_> 41168 is more than 10k ints
12:03:36 <xarick> CheckShipReverse is 41200
12:03:53 <xarick> ChooseShipTrack is at 41264
12:04:42 <Eddi|zuHause> it's *probably* not that bad if it doesn't recurse
12:05:27 <Eddi|zuHause> but on some systems stack might be very limited
12:07:31 <peter1138[d]> Yeah, `Tpf pf` is 41080 bytes alone.
12:07:51 <peter1138[d]> So don't worry about it in `FindNearestDepot`.
12:19:18 <LordAro> i'd quite like my computer to stop crashing
12:34:50 <Eddi|zuHause> second public doesn't harm anyone
12:36:55 <peter1138[d]> It's good practice to go public: protected: private: and not mix them up. But doesn't harm anything.
12:39:16 <peter1138[d]> m_open is 8200 bytes, m_closed is 32776 bytes.
12:39:50 <peter1138[d]> It is some kinda of large hash table.
12:44:06 <peter1138[d]> 1024 and 4096 elements each.
12:45:23 <peter1138[d]> Plus a self-expanding container that's a bit like a vector but does not move existing elements when it grows.
12:46:54 <peter1138[d]> And a binary heap with 2048 elements. Each of those elements is 8 bytes.
12:47:00 <peter1138[d]> This is incredibly memory hungry ๐
12:47:10 <peter1138[d]> Compared to stuff from 1995 ๐
12:49:55 <peter1138[d]> Got it down from 41080 bytes to 136 bytes, by using heap instead of stack. Still uses all that memory.
12:50:07 <peter1138[d]> Probably slower as there's another pointer to reference
12:53:44 <peter1138[d]> This is weird, slot.Detach() returns a boolean.
12:54:40 <_jgr_> There is more than overload of Detach
12:56:51 <peter1138[d]> Ahh, VS Code is helpfully giving me the wrong one.
12:57:19 <LordAro> 0x0 & 0x1 could be valid pointers
13:08:47 <peter1138[d]> Moving that allocation to heap doesn't seem to affect performance.
13:09:05 <peter1138[d]> But also, it works as it is now, so why change it ๐
13:10:55 <peter1138[d]> Hmm, my own builds seem slightly faster that the builds on Steam.
13:11:43 <peter1138[d]> Left mine, right Steam.
13:11:59 <peter1138[d]> "Competing for the same CPU time
13:32:28 <xarick> meanwhile... success! maxed vehicles.
13:33:20 <xarick> i asked for 500 groups though, got 534 ;|
13:33:20 <peter1138[d]> And what did we learn?
13:33:41 <xarick> should have created a savegame
13:33:53 <peter1138[d]> Does AI have the equivalent of "delete all vehicles in depot?"
13:34:21 <xarick> but they can kinda do it
13:46:45 <xarick> now I need to understand what the heck I need to do to use the region based code for ship depots
13:47:47 <xarick> already got this pointing to the correct functions, but seems I'm gonna need to duplicate some parts
13:49:35 <xarick> pick some of ChooseShipTrack code and apply it to FindNearestDepot, code repetition ๐
13:52:24 <xarick> YapfShipFindWaterRegionPath not sure what this is going to find when there is no destination tile set
14:06:35 <_glx_> reduced code flow is ```
14:06:35 <_glx_> res = GSText(GSText.STR_RED);
14:06:35 <_glx_> res.AddParam(GSText(GSText.STR_RANK));
14:06:39 <_glx_> STR_RED : {RED}{STRING}
14:06:39 <_glx_> STR_RANK : {NUM} - {COMPANY} with {NUM} points
14:07:48 <xarick> Kuhnovic assumes the dest tile is already known
14:08:19 <xarick> in this situation, we're looking for a dest tile instead
14:09:09 <_glx_> validation is very strict
14:10:47 <xarick> I don't think I will be able to do this on my own
14:33:51 <peter1138[d]> How does it handle multiple docks?
14:34:15 <xarick> not sure, but differently than the original
14:34:48 <xarick> but yeah, how it decides which one to pick, doesn't seem to be the one closest
14:35:41 <xarick> there's tile areas with docking tiles, need to check which one it takes
14:37:15 <xarick> one docking tile might even be unrearachble, but it seems to just pick whatever one it finds first?
14:38:16 <kuhnovic> The region pathfinder handles multiple docks by adding all of the regions that contain docking tiles for that particular station. Those regions are all added as start nodes (the region pathfinder actually searches the "wrong way around", there are good reasons for that, not going into that now)
14:38:53 <xarick> ah, so the dest_tile is actually the origin?
14:39:55 <kuhnovic> Yes, and that origin is the current ship position
14:42:05 <kuhnovic> So looking for ship depots isn't too dissimilar to looking for multiple docks / docking tiles
14:42:42 <xarick> uhm... I need to feed it all the ship depot locations? that's... bad
14:42:47 <peter1138[d]> Sort of. Multiple docks generally has a small area. Depots could be anywhere.
14:42:53 <xarick> they could be sparsed all over the map
14:44:20 <xarick> can't it just expand kinda breadth search or whatever it's called until it finds a depot match?
14:44:31 <xarick> i think it's breadth search, not sure
14:46:26 <xarick> search for a depot in adjacent regions to the ships location
14:46:36 <xarick> in breadth first style
14:47:33 <kuhnovic> The region pathfinder should be able to do something like that
14:48:13 <kuhnovic> It's all about having the right stop condition, so basically "stop when the first region with a depot (of the current player) is found"
14:49:22 <kuhnovic> We can definitely come up with something better than "iterate over all depots and try to find a path to each of them".
14:55:33 <peter1138[d]> Hmm, can I conditionally enable stuff from a StrongType mixin...
14:56:04 <peter1138[d]> if a StrongType has a specific mixin, I want different fmt::formatter()
15:12:50 <xarick> PfFollowNode is a bit complex
15:17:10 <xarick> I'm too noob for this ๐
15:21:06 <kuhnovic> Which part are you looking at specifically. YAPF stuff is hard to read due to the heavy templating.
15:24:49 *** Smedles_ has joined #openttd
15:27:45 <xarick> I'm unsure how big is the region
15:28:07 <xarick> max station spread can be 64x64
15:28:30 *** Smedles has quit IRC (Ping timeout: 480 seconds)
15:28:35 <xarick> meaning the docking tiles could be in 2 different regions
15:29:58 <xarick> there are no penalties or costs for these regions?
15:30:07 <xarick> must investigate this ๐
15:30:43 <kuhnovic> All regions are 16x16, this is fixed
15:31:37 <xarick> cost is manhattan distance based
15:31:40 <kuhnovic> And indeed, docking tiles can (and often do) end up in different, regions. That's why all docking tiles for a particular station must be checked, and each corresponding region is added as a potential start node.
15:32:20 <kuhnovic> xarick: The heuristic is manhattan based, and so is the region-to-region-cost
15:35:56 <xarick> doesn't take into consideration curve costs, eh... i guess it's fine
15:37:00 <xarick> aqueducts... hmm yeah I wonder how's this handled without costs
15:40:27 <kuhnovic> This is the tradeoff that has to be made. The regions are a high level abstraction of the map. This means it's able to search the entire map extremely fast, but it has to omit details like canal cost / curve cost.
15:42:00 <kuhnovic> The region pathfinder is only used to find an intermediate destination that is not too far away from the current location of the ship. The path planning do that intermediate destination is done with the regular ship pathfinder, so curve costs and other penalties are still taken into account at that level. But that's just locally.
15:44:03 <xarick> I'm gonna experiment feeding all depot locations to the regionfinder, maybe it's not that bad
15:44:47 <peter1138[d]> Change: Delay depot finding for ships to 1 year to avoid slowdowns ๐
15:45:14 <xarick> it's searching within this abstraction, so... it's fast, I heard
15:46:31 <kuhnovic> It's fast, but not if you create thousands of depots. And I've seen the stuff you do ๐
15:47:35 <peter1138[d]> Nope, I've no idea how this StrongType mixin stuff works.
15:53:40 *** Wormnest has joined #openttd
16:14:07 <xarick> 'SetIntermediateDestination': is not a member of 'CYapfShipAnyDepot' ... I'm too noob for this
16:17:11 <LordAro> you've been saying that for well over 5 years now
16:21:21 <peter1138[d]> /me explains, yet again, that adding on 10%, and the taking off 10%... needs to be done correctly ๐
16:26:34 <peter1138[d]> Hmm, can I get ->value (or ->base()) from a StrongType mixin
16:27:28 <_jgr_> You can use `static_cast<const TType &>(*this).base()` for that
17:28:03 *** gelignite has joined #openttd
17:30:50 <peter1138[d]> Holy header dependencies :/
17:31:01 <peter1138[d]> It's 1ยฐC and I've been invited out on the MTB.
17:31:03 <peter1138[d]> I'm... not sure.
17:32:29 <xarick> kuhnovic: is it possible for high_level_path fail to find a path and the other normal pf not fail?
17:34:14 <kuhnovic> No. If the high level pf fails to find a path them the low level pf will never be called.
17:34:23 <peter1138[d]> Hmm, okay, a template specialization without conditionals works.
17:34:55 <xarick> hmm okay, I see, then I could return eariler
17:36:27 <xarick> if (high_level_path.empty()) {
17:36:27 <xarick> return FindDepotData();
17:41:21 <peter1138[d]> Press the other button ๐
17:41:35 <kuhnovic> I think you need to just find the closest region with a depot in it, and return that depot. This will then become the target for the pathfinder. You could argue that you already know the path to the depot so you might as well return it, but that makes things more complicated.
17:44:08 <xarick> I saw a bit of code how it finds neighbour regions. It's all too new to me. I wonder what does it do inside the region other than looking if it's traversable from edge to edge
17:44:42 <xarick> it also looks for the other side of aqueducts inside the region, hmm
17:46:02 <kuhnovic> Indeed, and it checks which region patches (blobs of interconnect water within a region) are connected to other region patches in neighoring regions.
17:46:37 <xarick> a depot could be trapped inside the region, but the edges be accessible from all directions, I wonder how would it handle that
17:46:49 *** HerzogDeXtEr has joined #openttd
17:47:13 <kuhnovic> That what the region patches are for
17:49:56 <kuhnovic> Each region uses Connected Component Labeling (CCL) to figure out which parts of water are connected and which are not. If you have say a lake in the middle, and that lake has a depot on it, then all the lake water will have a different so called "label" than the water at the edges of the region. This means it's not interconnected and not reachable, at least nog from within that region.
17:50:44 <kuhnovic> But all of that was abstracted away behind the VisitRegionNeighbours function or something like that, I forgot the exact name
17:53:48 <xarick> I wonder 4096x4096 maps, how many labels will be generated ๐ also 64k depots, because keks
17:56:45 <xarick> meanwhile... I used lzo though, map is 128x128
18:12:51 <xarick> wow, it's slow for 4k maps ๐
18:13:05 <xarick> map generation takes a bit long
18:14:19 <xarick> scans every tile traversability for each region and each region can have 256 patch labels? hmm not sure I'm reading this correctly
18:15:33 <andythenorth> try it on JGRPP 16k maps and report back ๐
18:16:23 <kuhnovic> Labels are only unique within their own region. Most regions will only have 1 label, some will have a couple. Very few end up with a high label count, unless you try really hard haha
18:17:21 <xarick> how does it treat river slopes
18:17:32 <xarick> traversable? non-traversable?
18:18:53 <kuhnovic> If a ship can traverse it, then it's treated as such by the region labeling. So river slopes are not traversable.
18:21:52 <xarick> looks like it's fool proof
18:22:37 <peter1138[d]> We have a lot of fools
18:22:59 <kuhnovic> Just a matter of time before a better fool shows up
18:23:54 <kuhnovic> I'm not going to claim that it's bug free, but I did spend a lot of time trying to get the kinks out.
18:24:22 <xarick> I am finally understanding this approach
18:24:51 <xarick> it's quite expensive at game start
18:25:05 <peter1138[d]> Aircraft pathfinder next?
18:25:50 <xarick> next thing I'll do is remove buoys from my AI once this is merged
18:27:03 <xarick> i wanna test how this handles canals inland, I had a testing AI that would generate canal routes
18:27:18 <xarick> need to check if it's still up to date
18:28:27 <xarick> it was done when the concept of docking tiles didn't exist, it only considered the tile in front of the dock
18:35:48 <kuhnovic> peter1138[d]: What's wrong with the Aircraft pf?
18:39:51 <Rubidium> a fast aircraft is more likely to land than a slow one?
18:40:15 <DorpsGek> - Update: Translations from eints (by translators)
18:43:33 <truebrain> peter1138[d]: Lol, are we going to add air corridor? ๐
18:47:55 <xarick> very sad expression of disappointment
18:48:58 <xarick> oh, suddenly it found a path
18:51:53 <peter1138[d]> Uh... where has code gone ๐ฎ
18:52:21 <peter1138[d]> Out of memory: Killed process 3127231 (openttd) total-vm:35458356kB, anon-rss:33021196kB
18:52:55 <xarick> can a GS post some news focusing on a vehicle?
18:53:11 <xarick> I wanna make a GS that detects lost ships and make it news!
18:53:18 <xarick> lost ships of other companies
18:53:43 <peter1138[d]> 33GB is only half my memory, that's silly.
18:54:38 <_heresy> If this is using WSL, then WSL is default to only use 50%
18:57:08 *** gelignite has quit IRC (Read error: Connection reset by peer)
18:57:41 *** gelignite has joined #openttd
19:33:04 <truebrain> orudge: so about notarizing other apps next to OpenTTD .. when we do that on the same account etc, does that cost extra money? Or do we just need to add it to the list somewhere or something?
19:40:02 <truebrain> right, going to merge #18 in the hope the workflow works .. can't test before I merge, so ... yeah.
19:45:11 <xarick> truebrain: uh, nope, it doesn't
19:46:25 <truebrain> let's see where I failed with the GitHub workflow ..
19:46:46 <truebrain> `Start date 2024-01-01 is not in week 1 of 2024, but in 2024-01` .. great ... `1` vs `01` ๐
19:49:13 <LordAro> broke it immediately :p
19:50:05 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:51:54 <truebrain> okay, that commit went into the wrong repository, but otherwise is doing what I assume ๐
19:56:24 <kuhnovic> truebrain: Unfortunately not. Nearest depots are still found based on manhattan distance. If that depot happens to be in a body of water that the ship can't reach then you'll still get a lost ship.
19:56:51 <kuhnovic> The approach that xarick is taking is much better
19:57:23 <xarick> teh conflicts I need to solve
19:57:42 <kuhnovic> And now I'm going to pop open a cold one to celebrate that merge!
19:58:13 <truebrain> `Changes must be made through a pull request. `
19:59:28 <xarick> it's not just conflicts... the region finder wasn't properly made for unknown destinations from the go, it's gonna take a while for me to figure out what to do
19:59:49 <xarick> currently experimenting with feeding all depot locations
19:59:56 <kuhnovic> I'll help you with that
20:00:16 <talltyler> ^^ updated with info from this conversation
20:01:22 <talltyler> But congratulations and thank you to kuhnovic for an awesome contribution to OpenTTD! I canโt wait to play another boat-heavy game! Maybe Iโll break out Industries of the Caribbean or my old canalboat GRF sometime. ๐
20:02:40 <truebrain> hmm ... the commit to add a summary to survey-web is not announced here ofc
20:02:48 <truebrain> do we want a weekly reminder a new summary is available?
20:03:47 <LordAro> kuhnovic: well done :)
20:03:47 <truebrain> owh ... a new commit via GitHub Actions doesn't trigger the workflows ... oof
20:06:48 <kuhnovic> Thanks guys, I really appreciate it ๐
20:15:53 <truebrain> kuhnovic: one of the biggest non-dev PRs in a long time ๐
20:16:27 <truebrain> okay ... this should be it
20:16:43 <DorpsGek> - Add: summary for week 01 of 2024 (by OpenTTD Survey)
20:17:07 <truebrain> takes a few seconds before it is published, but those are details
20:17:59 <truebrain> should happen every Monday at 0700
20:18:06 <peter1138[d]> Back when GRF IDs had letters ๐
20:18:34 <andythenorth> I thought I'd got over those emotional wounds ๐
20:19:40 <andythenorth> ` grf_name="iron-horse",
20:19:40 <andythenorth> grfid=r"CA\12\22",
20:20:01 <andythenorth> that was me, ruining the game
20:21:56 <truebrain> there was also a nightly again a bit ago \o/
20:25:20 <xarick> hmm... this DistanceManhattan as costs....
20:46:54 <xarick> the pathfinder receives a max_cost when using automated service depot order
20:48:00 <xarick> the region pf'er way of calculating the costs... erm, you know it's not gonna be the real cost, but it should really be the most approximation possible
20:48:41 <xarick> it's a difference between... servicing or not servicing
20:49:29 <xarick> and using distancemanhattan is the main culprit for issue 5713
20:51:57 <xarick> maybe I'm wrong, but k let me test
20:52:30 *** gelignite has quit IRC (Quit: Stay safe!)
20:52:49 <andythenorth> do people want to do steam tourist trains in 2020 or so?
20:54:44 <peter1138[d]> Please stop switching timebase :S
20:56:47 <talltyler> I thought you were talking to me for a moment ๐
20:57:32 <talltyler> Many, many rebases ago one of my timekeeping branches was named `tyler-ruins-time`
20:59:22 <peter1138[d]> talltyler: prophetic?
21:00:15 <talltyler> Anticipating the forum posts ๐
21:00:52 <talltyler> I think that was when wallclock mode was mandatory instead of a new setting
21:01:18 <peter1138[d]> In doing this cargo clean up I'm distraught.
21:01:22 <peter1138[d]> We have... cargotype.h
21:01:56 <peter1138[d]> There is absolutely no way that cargo can be disentangled from newgrf cargo...
21:11:04 <truebrain> peter1138[d]: It is so annoying, but never annoying enough to actually fix it ๐
21:13:22 <Eddi|zuHause> well, one deals with the programming language types that deal with cargo, one deals with the ingame concept of cargo types, and one deals with the newgrf interface
21:13:41 <Eddi|zuHause> perfectly logical?
21:14:19 <peter1138[d]> You've never looked at them then ๐
21:14:54 <peter1138[d]> Most of cargotype.h/cargo_type.h should be merged
21:15:01 <peter1138[d]> And then the functions should be in cargo_func.h
21:24:35 <andythenorth> cargotype and cargo_type eh
21:26:51 <peter1138[d]> What's CT_DEFAULT_NA used for...
21:26:59 <peter1138[d]> Stations 0xFE. Hmm.
21:27:53 <peter1138[d]> So "NA" means... zero waiting cargo?
21:28:45 <orudge> truebrain: sorry, getting kids to bed and so on took a bit longer than I'd hoped. Looking at the notarization stuff now though :)
21:29:35 <peter1138[d]> Ah, indeed, newgrf_cargo.h used to have more in it but more and more was needed everywhere...
21:29:39 <andythenorth> lol GPT literally telling lies
21:29:54 <andythenorth> it's so good for some jobs, and fails on basic facts, still, even in v4
21:29:57 <Eddi|zuHause> what else is new?
21:30:05 <peter1138[d]> GPT fabricating a likely response based on language...
21:30:14 <peter1138[d]> It is not a fact checker...
21:30:14 <andythenorth> it's parroting me wikipedia pages about trains, but just using the wrong ones
21:30:21 <andythenorth> it's such a confident liar
21:30:33 <andythenorth> which is why it's also great for stuff like thinking up naming schemas ๐
21:30:44 <Eddi|zuHause> that's the primary feature of GPT... making up stuff that sounds plausible and blasting it at you with utmost confidence. it has no concept of truth
21:32:25 <Timberwolf> andythenorth: asking it for a list of "UK freight locomotives from the 1800s" was fun.
21:32:55 <andythenorth> good alternative history?
21:33:01 <Timberwolf> It told me very excitedly about the GNR Stirling Single 2-10-0 and its wide usage as a freight locomotive.
21:33:46 <Eddi|zuHause> that's certainly a thing that existed in the 1800s. 5-coupled engines
21:33:48 <andythenorth> we should include that
21:34:17 <Timberwolf> Only if it has the same driving wheel diameter.
21:35:18 <andythenorth> 2-10-0, 5 different sized wheels?
21:35:25 <andythenorth> and hub gearing on the cranks
21:36:06 <Timberwolf> That sounds highly plausible for mid-Victorian metallurgy.
21:36:34 <Eddi|zuHause> my googling surfaced the first 2-10-0 "decapod" engines were built in 1886 by Baldwin (USA)
21:38:11 <Eddi|zuHause> and the first example in austria in 1906
21:38:19 <andythenorth> I am mostly just using GPT for names
21:39:28 <Eddi|zuHause> for GB, says here there were never realized 1913 and the first actually built ones in 1943
21:40:17 <Timberwolf> Yeah, they're pretty late here.
21:40:40 <Timberwolf> There's a couple of 0-10-0s which were used for banking engines.
21:41:38 <xarick> what is !node? Node is not a bool...
21:43:01 <Eddi|zuHause> it'll be implicitly cast to bool (i.e. tested for 0 or not 0)
21:43:41 <xarick> oh node == nullptr I meant
21:44:28 <Eddi|zuHause> probably a C leftover
21:44:50 <xarick> leftover? this was just merged
21:45:28 <_jgr_> There is no ambiguity in what it means
21:45:28 <Eddi|zuHause> i mean, C-mindset
21:45:55 <Eddi|zuHause> it's a stylistic choice.
21:48:24 <xarick> while (node->m_parent != nullptr)
21:50:20 <xarick> I don't need to use the cache, but I do need to know the full path, need to adapt this piece of code
21:51:05 <xarick> and I wonder what kind of cost it's gonna give me
21:51:13 <xarick> probably the correct one
21:51:28 <peter1138[d]> It is a mistake, our coding style asks for !=/== nullptr.
21:52:27 <peter1138[d]> But otherwise it is perfectly valid ๐
21:59:39 <xarick> can the region pf handle two trackdirs
22:00:25 <xarick> oh nevemind, this is the low-level pf already
22:02:59 <peter1138[d]> Oh because pressing tab doesn't insert tabs if the file does not already have tabs ๐
22:06:23 <orudge> truebrain: so there are a couple of issues. The main one is that the dylib files inside the .app aren't signed. But there's also the issue that the .app isn't actually an .app, which will likely fail notarization anyway.
22:06:39 <orudge> Presumably it's just the actual .dylib files we want in a zip file?
22:07:09 <orudge> The app itself is signed correctly, but there's nothing of any substance in it, because it's missing a main binary
22:07:18 <truebrain> But okay, more curious how Apple Notarizing works .. can we just notarize any app?
22:07:20 <orudge> The dylib files in the Contents/Resources folder are not signed
22:08:04 <orudge> To see the error log, you can run: xcrun notarytool log CREDENTIALS request_uuid
22:08:10 <truebrain> A zip etc doesn't work .. the basic issue is that MacOS sees it is downloaded any not from a notarized source
22:08:13 <orudge> where CREDENTIALS is generally --profile openttd or whatever we did
22:08:37 <orudge> I don't think you can notarize a single .dylib
22:08:50 <truebrain> Documentation says it is possible
22:09:02 <truebrain> But I guess I need to tickle CMake a bit more
22:09:20 <truebrain> We tried signing the dylib alone first
22:09:42 <truebrain> But then MacOS says it is signed, but still fails opening it, as it wasn't notarized ๐
22:10:38 <truebrain> I do understand why MacOS wants the dylib come from a notarized source ๐
22:12:26 <orudge> Could we create a .pkg installer that places the .dylibs in the intended place? (Is there a specific expected location?)
22:12:41 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:13:12 <orudge> So you can notarize a dylib, but you can only staple the notarization token to an .app or signed installer package, it seems.
22:13:19 <orudge> Not to a .zip or a .dylib
22:13:35 <truebrain> Yup; hence the dmg ๐
22:14:00 <xarick> yippie! Finally integrated FindNearestDepot with region pf. If a penalty of 2000 is used, I guess there's no point in using the high level search
22:14:20 <truebrain> And sure, pkg would work too, but I guess it is CMake being a bit annoying ๐
22:14:46 <truebrain> dmg does support dylib only things searching suggests
22:16:22 <orudge> Just testing a .dmg containing only the .dylibs now
22:17:06 <orudge> OK, that seems to work
22:17:15 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
22:17:15 <truebrain> Not having access to an actual MacOS made it .. challenging ๐
22:17:17 <wensimehrp> TallTylerviaGitHub: Ugh, how to translate "wallclock mode"...
22:17:56 <truebrain> Okay, so it is mostly CMake that I need to tell to sign the dylib I guess ๐
22:18:11 <orudge> So, what I'd suggest: ditch cpack (or have it not create an .app somehow), manually sign the two .dylib files, use hdiutil to package them into a new .dmg, submit for notarization, staple it
22:18:51 <orudge> I can update release-macos.yml to do this if you like, you may want to tweak things of course
22:19:06 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:19:23 <truebrain> orudge: I would really like to avoid doing it all manually. CMake should be able to do it, I just guessed wrong where it broke ๐
22:19:49 <truebrain> Btw, any suggestions to make installing easy for the user? The install.txt feels a bit meh
22:20:06 <orudge> truebrain: probably a .pkg installer :)
22:20:21 <orudge> though I don't think macOS packages let the user specify an installer folder
22:20:35 <xarick> Which one is better correct, the standard of finding ship depots?
22:20:35 <xarick> `IsShipDepotTile(tile) && Depot::GetByTile(tile)->xy == tile && IsTileOwner(tile, v->owner)`
22:20:35 <xarick> `IsShipDepotTile(tile) && GetShipDepotNorthTile(tile) == tile && IsTileOwner(tile, v->owner)`
22:20:35 <xarick> `IsShipDepotTile(tile) && GetShipDepotPart(tile) == DEPOT_PART_NORTH && IsTileOwner(tile, v->owner)`
22:24:01 <truebrain> Hardest issue is that I can't actually test any of it ๐
22:24:20 <orudge> truebrain: you can alternatively ship a shell script, I guess... maybe even an .app that uses a shell script as its main binary!
22:24:25 <truebrain> Still surprised CMake doesn't sign the dylibs.. bit odd
22:24:39 <orudge> but a .pkg may be nicer :D
22:25:38 <truebrain> "You should list any frameworks and plugins that are included in your app bundle." .. I could just read ...
22:26:00 <truebrain> Seems CPack can create a pkg too, but I need actual access to a Mac to figure that out
22:26:34 <orudge> It looks like a Mac app based on a shell script is actually possible; you could have it use AppleScript to pop up a dialog to confirm it for the user and so on. But a pkg is probably still nicer :D
22:28:40 <truebrain> not disagreeing, just not something I can deliver ๐
22:29:24 <orudge> truebrain: if you are wanting/able to try to persuade CPack to produce a correctly signed/notarized dmg with the two dylibs, I can likely help with some form of distribution mechanism (pkg or app). But I don't know that I have the time to wrestle cpack into signing everything correctly.
22:29:58 <truebrain> I think we should use cpack where possible, as that means we don't have to maintain it
22:30:35 <truebrain> so if I sign those 2 dylibs in that dmg, notarizing works, you say?
22:30:37 <truebrain> let me fix that then
22:31:15 <orudge> Basically. But CPack modifies them as part of the packaging process (strips them I think)
22:31:28 <truebrain> yeah, that is all already dealt with etc
22:31:46 <orudge> so you need CPack to do the signing. And unfortunately the CPACK_BUNDLE_APPLE_CODESIGN_FILES variable that's meant to do that seems not to work.
22:31:52 <orudge> It's adding an extra -i into the command line for some reason
22:31:58 <orudge> which codesign doesn't like.
22:32:31 <orudge> (i.e. adding two "-DCPACK_BUNDLE_APPLE_CODESIGN_FILES=/Contents/Resources/blahblah.dylib" lines to the cmake command line)
22:32:34 <truebrain> it does `-i <bundleid>`
22:32:42 <orudge> hmm, but there's no bundle ID there
22:33:14 <orudge> maybe you need to manually specify that
22:33:19 <truebrain> lol, why did it pick that repo? Owh well ...
22:34:22 <truebrain> odd, it is the only reference to `CPACK_APPLE_BUNDLE_ID`
22:34:25 <truebrain> that clearly is buggy ๐
22:38:05 <talltyler> Okay, now time to build binaries for a PR test game ๐
22:38:37 <talltyler> Time for the Europeans to go to sleep so I can hog the actions ๐
22:39:40 <talltyler> Unused strings? What a stupid rookie mistake ๐
22:42:13 <orudge> Add that to the cmake command line, and your frankenbinary will be successfully signed and notarized
22:42:51 <truebrain> don't be making fun of our binaries!
22:43:07 <truebrain> now the main question is ... does MacOS now like it when you install it like that .. or will it still give such an annoying popup ..
22:43:36 <truebrain> ```get_target_property(LIBRARIES ${PROJECT_NAME} LINK_LIBRARIES)
22:43:36 <truebrain> string(REGEX REPLACE "([^;]+)" "/Contents/Resources/\\1.dylib" LIBRARIES "${LIBRARIES}")
22:43:36 <truebrain> set(CPACK_BUNDLE_APPLE_CODESIGN_FILES "/Contents/Resources/lib${PROJECT_NAME}.dylib;${LIBRARIES}")```
22:43:42 <truebrain> hopefully that does something similar as to what you have ...
22:44:21 <orudge> truebrain: I can then fairly easily turn that .app into something a bit more user-friendly :)
22:45:03 <truebrain> even via CPack? ๐
22:45:44 <peter1138[d]> Can't you just do it all on andy's MBP?
22:47:05 <truebrain> anyway, so the answer to my main question: is this all covered under the single 100$ fee of Apple?, is yes? ๐
22:47:53 <orudge> truebrain: yes, and yes
22:48:11 <truebrain> I am now cooking a binary via the CI that should be a valid dmg
22:48:18 <truebrain> you can take it from there if you like, to make it prettier ๐
22:48:41 <truebrain> (as this CMake stuff needs to be shared by 3 other repos, I am trying to make the MacOS part generic, so I can just copy the files to the other repos ๐ )
22:50:48 <truebrain> okay .. that seems to work \o/
22:53:46 <orudge> the dmg seems to work. The dylib is rejected by spctl because it's not an app.
22:54:31 <truebrain> does it actually load the dylib?
22:54:53 <truebrain> (important to use the download as source; not a version you cooked yourself btw)
22:55:22 <truebrain> and no, you don't need to actually have Discord for it to load ๐ It will just return that it can't detect Discord
22:57:45 <orudge> I will try that out in a moment
22:57:54 <truebrain> would be much appreciated ๐
23:08:54 <xarick> need to do the ultimate test
23:09:17 <xarick> 4096x4096 map, 64000 ship depots
23:09:53 <xarick> 75000 ships maybe? maybe just 1
23:10:35 <truebrain> pff, need to create an account on CMake's Gitlab instance to report a bug; no tnx
23:11:11 <orudge> truebrain: yep, looks like it works
23:11:28 <truebrain> that means I can now produce plugins for all major OSes; that is awesome ๐
23:11:45 <truebrain> tnx for the help orudge
23:11:59 <truebrain> I really did not expect "Resource Not Found" error to mean: your dylibs aren't signed .. ๐
23:12:34 <orudge> truebrain: it doesn't. It means no ticket was found to staple :)
23:12:45 <orudge> you need to retrieve the error log manually
23:13:07 <truebrain> it doesn't really change anything about what I said ๐ ๐
23:13:30 <truebrain> anyway, if you have improvements to my CMake bla, please let me know. All improvements to make MacOS is highly appreciated
23:13:38 <orudge> I will send you some stuff :)
23:13:51 <truebrain> it also means I need to rethink how we are going to do this via BaNaNaS .. meh
23:13:57 <truebrain> Linux and Windows were easy ๐
23:14:13 <truebrain> but okay .. one problem at the time!
23:14:48 <truebrain> tomorrow I first copy this stuff to the Steam plugin, see if it works there too .. then I can create the GOG, then we can merge it all and be done before 14.0 ๐
23:17:37 <orudge> but this includes a very basic UI for an installer, which copies the files to the appropriate location
23:17:55 <orudge> and is easily customised for Steam, etc
23:18:04 <orudge> Do with it what you will :)
23:18:26 <truebrain> what extension is that InstallPlugin?
23:18:30 <truebrain> I don't like extension-less files ๐
23:18:40 <orudge> I don't know for sure if Apple would reject an extension there
23:18:47 <truebrain> owh, it is a shell-script .. I can name it `.sh` in our repo ๐
23:21:24 <truebrain> what is up with that `CFBundleIconFile`?
23:21:38 <orudge> that's what macOS uses to identify which icon to display for an app bundle
23:21:46 <orudge> i.e., it points to the .icns file with the same name
23:21:58 <truebrain> ah, so the name is wrong; k, I can fix that ๐
23:22:16 <orudge> what name is wrong, sorry?
23:22:29 <truebrain> `OpenTTD-discord-social`
23:22:33 <truebrain> should be `openttd.icns` I guess ๐
23:22:55 <orudge> Maybe it's a CPack thing
23:23:00 <truebrain> that is what OpenTTD does ?
23:23:09 <orudge> because the file in Contents/Resources is called OpenTTD-dsicord-social.icns
23:23:15 <orudge> except spelled correctly
23:23:23 <truebrain> ah, okay, but so you are still missing `.icns`
23:23:28 <orudge> that's Apple for you :D
23:23:36 <orudge> (I did test it and the icon showed up)
23:23:37 <truebrain> ... so then OpenTTD's Info.plist is wrong ๐
23:23:48 <truebrain> it can't both be right! ๐ฎ
23:24:08 <orudge> OpenTTD is probably fine because the app is called OpenTTD.app (and macOS file systems are case-insensitive)?
23:24:22 <truebrain> it has `.icns` ๐
23:24:31 <truebrain> that is why I am a bit confused by the extension or not ๐
23:24:46 <orudge> Well convention is that it doesn't include .icns I think
23:24:51 <orudge> but maybe macOS does support both
23:25:35 <truebrain> `A legacy way to specify the appโs icon. Use the CFBundleIcons or CFBundleIconFiles keys instead.`
23:25:47 <truebrain> `The filename you specify does not need to include the extension, although it may`
23:26:35 <truebrain> cooking a new dmg .. let's see if I managed to apply your changes correctly ..
23:28:19 <truebrain> sadly takes 5+ minutes, as the Rust cache doesn't want to behave (a weird GitHub Caching quirk)
23:29:23 <truebrain> owh, the install-script is slightly wrong, but nothing you could know
23:29:30 <truebrain> files should be in a subfolder for optimal usage
23:29:42 <orudge> Ah OK. It did seem to work as it was, anyway :)
23:29:55 <truebrain> yeah, it does, but if you would have more than one version installed, things act weird
23:30:03 <truebrain> the one library finds the other based on the path of the first
23:30:16 <truebrain> the one thing I still struggle with, is versioning
23:30:36 <truebrain> but that is a OS-unrelated thing
23:30:44 <truebrain> (you can't have more than one plugin for the same platform active)
23:32:27 <truebrain> I guess for now I can make MacOS act the same as the other platforms, and name the subfolder `discord-<version>`, and figure out how to deal with all this later
23:32:37 <truebrain> but okay, very minor details at this point ๐
23:33:43 <orudge> Now, I don't know that I actually tested notarizing it with the script, hopefully it works :D
23:35:17 <orudge> truebrain: seems to work fine here :)
23:35:24 <truebrain> it installed fine too? Nice ๐
23:35:26 <truebrain> and please check if version of the dylib etc is also correct
23:36:07 <orudge> truebrain: well it copies it over (to the social_integration folder, not a subdir) and I get the "Discord is not running" debug error
23:36:22 <truebrain> and yeah, the subdir fix is not in that build yet ๐
23:36:58 <orudge> So yes, it all looks good on this Mac at least. Haven't tested my Apple Silicon Mac but I imagine it would be fine there too.
23:37:14 <truebrain> yeah, the universal part already works, I know ๐
23:37:30 <truebrain> tnx a lot! This made it go a lot quicker ๐
23:37:34 <truebrain> and I like your installer solution ๐
23:37:54 <orudge> It's nothing fancy but it should do the job
23:38:18 <truebrain> it doesn't have to be fancy ๐
23:38:28 <truebrain> most users will get it pre-installed via Steam install anyway ๐
23:38:35 <truebrain> this is just for the select few that like to do things manually
23:39:02 <truebrain> okay, bit late for me, so off to bed. Tnx again!
23:39:29 <xarick> I don't understand the warning... when will it not return a value? I don't see it
23:41:24 <peter1138[d]> There's no return after the loop
23:41:49 <xarick> it doesn't need to, why bother complaining
23:42:03 <xarick> the loop is always going to return something
continue to next day โต