IRC logs for #openttd on OFTC at 2023-11-05
โด go to previous day
01:01:34 <peter1138> IA64 removed from Linux...
01:05:35 <goddess_ishtar> does anyone actually *use* Itanium these days though?
01:50:53 *** Wormnest has quit IRC (Quit: Leaving)
02:27:41 *** Tirili has quit IRC (Quit: Leaving)
03:40:47 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:11:34 *** D-HUND is now known as debdog
06:10:52 <goddess_ishtar> just checking, pull request comments are open to anyone right?
06:12:07 *** _pruple has joined #openttd
07:13:07 <LordAro> _pruple: stop finding bugs!
09:25:50 *** pemensik|home has joined #openttd
09:40:48 <truebrain> Ah, the biased: it is asked about a lot where I reside, so it is in demand ๐
10:16:37 <andythenorth> emotionally spinning in the wind
10:16:49 <andythenorth> 'do they love me? will they love me?'
10:41:58 <michi_cc[d]> Changing the default station cargo view to via-dest-source would definitely make sense, regardless of the state of the actual cdist settings.
10:42:29 <merni> What's the default now?
10:42:43 <truebrain> didn't we change that already recently to something?
10:47:06 <goddess_ishtar> the station cargo view is kinda a mess
10:48:17 <goddess_ishtar> I honestly think that the group-by option should be hidden without cargodist because it does nothing in that case, and that "Via" should be renamed "Next" because "Via" implies that it's not the final destination
10:48:26 <goddess_ishtar> which isn't necessarily the case
10:53:25 <michi_cc[d]> truebrain: Good question ๐ I just see the "switch view to see what is actually going on" answer a lot. But maybe we did change it and most people just have too "old" config files ๐
11:16:26 <andythenorth> imagine being cdist
11:17:02 <andythenorth> you were crafted, loved, wanted, fought over, taken care of, and released into the world, full of conflict
11:17:12 <michi_cc[d]> One of these says YACD will get a resuscitation.
11:17:56 <andythenorth> now cdist is in a cycle of rejection, abandonment, and anxious attachment
11:18:00 <andythenorth> some want it gone
11:18:05 <andythenorth> some are fearful it will be gone
11:18:25 <andythenorth> some have view that we need to settle as it's the best we will get
11:18:35 <andythenorth> some truly love it
11:19:03 * andythenorth has been down a human attachment rabbit hole and is now projecting it onto inanimate objects
11:19:09 <alfagamma7> cargodist needes to be improved
11:19:32 <alfagamma7> Openttd is not playable without it
11:31:13 <_jgr_> TTD didn't have it and plenty of players do without it
11:32:05 <_jgr_> It's only really "necessary" if you want to build a transport network, instead of a collection of point to point links
11:36:07 <_jgr_> Speculating a bit, it may be an idea if more of the cargodist policy/settings was settable from GRF, so that industry GRFs could just configure it "properly", (potentially with a more fine-grained or callback-based demand allocation layer if we wanted to really push the boat out), without pushing that onto players
11:38:53 <Eddi|zuHause> the problem with making it grf-configurable is that it needs to be sane with grfs that don't set anything (i.e. all existing grfs)
11:42:40 <_jgr_> Yes, that is the current state of affairs
11:43:37 <_jgr_> Proposing an extra GRF feature does not imply that everything that came before must be removed
11:48:58 *** pemensik|home has quit IRC (Remote host closed the connection)
12:29:18 <peter1138> The other day I learned that cargo doesn't have destinations
12:52:44 <_glx_> yeah it's "dist" not "dest"
13:04:03 <andythenorth> do you never use it in games? ๐
13:05:03 <peter1138> I think my networks are always simple enough that it looks like it does.
13:20:48 <andythenorth> how it actually works only shows up in more complex cases
13:24:45 <merni> michi_cc[d]: Or are playing 13.4 rather than nightlies?
13:58:02 <_jgr_> So what does YACD do that cargodist does not?
13:58:26 <_jgr_> I'll admit that I don't really understand why it's touted as the solution to some unspecified problem
14:00:14 <peter1138> the "unspecified problem" is that cargo should want to go to specific places, not go where the player decides.
14:01:10 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
14:05:28 <_pruple> otoh, a) why would you, as a producer, deliver cargo to a station to be put on a vehicle that isn't taking it where you want it to go?
14:07:01 <_pruple> and b), isn't having the game tell the player what industries they need to connect instead of letting them decide for themselves a backwards step in the fun and creativity of the game?
14:07:38 <peter1138> Your phrasing on a) is odd, I can read that as supporting CargoDest.
14:08:21 *** virtualrandomnumber has joined #openttd
14:08:49 *** virtualrandomnumber has quit IRC ()
14:10:08 <_pruple> well, to put it another way, if I'm running a fruit farm and the train outside the gate goes to processing plant A, am I going to sign a contract with processing plant B and let the fruit rot in the field until someone builds another railway? ๐
14:12:44 <andythenorth> YACD assigns destinations on a per industry / per town basis
14:12:52 <andythenorth> michi_cc[d]: can explain it better though
14:19:00 <michi_cc[d]> _pruple: With YACD, I imagine it more like the Railroad Tycoon 3 model, where there is invisible 3rd party transport for stuff the player doesn't do.
14:19:40 <michi_cc[d]> The basic premise of YACD is that suppliers and consumers have pre-determined relationships.
14:21:09 <michi_cc[d]> So it is basically either some on-map company that performs the transportation or invisible other transport (which is of course more expensive so industries might close down if they can't find cheap transport).
14:22:55 <michi_cc[d]> Mail and pax are similar. Towns have a list of other towns (and certain industries like oil rigs) that are preferred destinations. This is can be imagined as the predominant flows for e.g. work commuting or locations with closer personal ties.
14:25:48 <michi_cc[d]> The routes are assigned by a more or less clever algorithm that takes several different variables into account. For industries for example it starts with making sure each industry has a supplier for all needed cargoes, this supplier is weighted by distance, but will still spread the links out if a source already has more links that average.
14:27:02 <michi_cc[d]> After this first round, additional routes are created up to a maximum based on the industry production to spread cargo around. There's some dynamic weighting of the routes by service, so industries will send more to serviced routes than unserviced routes.
14:29:41 <michi_cc[d]> For towns, the process is somewhat similar, just with a higher total amount of routes to make the flows more interesting. Cities will focus routes on longer distance routes to other cities and large towns, while normal towns get routes much more heavily weighted by geographic proximity and to the closest cities.
14:30:44 <michi_cc[d]> For house cargoes in particular, actual destinations are just not the sign of the other town, but proper tiles all over the town.
14:33:18 <michi_cc[d]> YACD has some advantages and some disadvantages over cargodist. The biggest advantage is that cargo/pax behave a lot more naturally as you would expect. With cargodist, it can easily happen that more or less a complete large cities suddenly wants to travel to a single station in a tiny town you've just extended your network to, as it doesn't care at all about the "surroundings" of your stations.
14:34:12 <michi_cc[d]> YACD allows a lot more natural game progression as cargo naturally scales with the size and area of the network as more and more services are established.
14:34:53 <michi_cc[d]> The big disadvantage is of course that it "prescribes" gameplay somewhat, as you are not free to just build whatever you want anymore.
14:36:12 <michi_cc[d]> And unfortunatly, doing tile-specific cargo routing is simply computationally expensive. YACD works, there are enough old binaries on the forums, it just wasn't fast enough for larger maps in it's last iteration.
14:36:25 <michi_cc[d]> If anyone is still reading: Wall of text over ๐
14:44:18 <_pruple> It's an interesting idea, sure, and I'm sure it's a lot of fun to develop
14:49:21 <_pruple> but it kind of feels like... a feature designed to work with the way most people build networks anyway. A feature that exists because it can. a classic BAD FEATURE. ๐
14:50:15 <_jgr_> I don't think it's a bad feature
14:51:22 <_jgr_> Having a way for the game to suggest connectivity would be interesting for a lot of players
14:52:10 <_jgr_> I'm not so sure that a different routing policy must mean slow tile-specific routing
14:53:00 <_pruple> "BAD FEATURE" doesn't mean bad feature per se. And yes, it might be interesting to have a dist/dest system that works better than the current cargodist.
14:54:42 <_jgr_> The existing cargodist model can be made to scale and perform quite well, even if policy leaves something to be desired
14:57:24 <_pruple> it's not terrible, it just so often seems to fall down on the mindreading once networks get to a certain level of complexity. but I think that's a dist vs dest problem, ie cargo will not get on an a -> b -> c service when it wants a -> d -> c.
14:58:46 <_pruple> can we resurrect YACD and get rid of juge maps? ๐
15:16:20 <merni> "nothing changes, except correctness" ๐
15:17:04 <peter1138> It's funny because the entire point of making StrongTypes is to make sure it's correct :D
15:45:52 <peter1138> Hmm, 30 minutes to do CI these days then.
15:46:04 <peter1138> Probably need to offload it to a MBP.
15:46:52 <peter1138> > fatal error C1090: PDB API call failed, error code '23': (0x000006BA)
15:46:56 <peter1138> That sounds interesting.
15:59:38 <Rubidium> yeah. I'd first try a rebuild of the failed job, and hope it's some random memory corruption
16:28:08 <Rubidium> peter1138, I reran the job and now it succeeded without issues
16:38:53 *** Wormnest has joined #openttd
17:03:54 <Eddi|zuHause> <_jgr_> So what does YACD do that cargodist does not? <-- the very short version is that a) YACD assigns a destination to the cargo packet at the beginning, and sticks to it, wheras CDIST assings a next hop on each unloading step, sending a fraction of cargo in various directions, which may reassign destinations. and b) YACD works on the whole map, assigning destinations to unconnected areas (and immediately
17:03:56 <Eddi|zuHause> dropping the cargo) wheras CDIST only acts on the current network.
17:04:54 <Eddi|zuHause> the result is that a) could potentially backfire in CDIST when links get congested, or networks get complicated. think like "turbulences" in water flow
17:05:13 <Eddi|zuHause> and the result of b) is that in CDIST, extending your network might make things worse
18:37:16 <DorpsGek> - Update: Translations from eints (by translators)
18:39:01 <peter1138> std::domain_error seems to be strong tied to mathematical stuff.
18:52:31 <peter1138> Should an industry that can't produce or consume a valid cargo type be disabled?
18:55:35 <talltyler> Thereโs a farm field industry that does nothing but spawn fields
18:55:53 <talltyler> Not saying thatโs a good idea, but it would break
18:57:31 <talltyler> Oh, that .base() PR is very nice! ๐
19:00:59 *** Xaroth92 has joined #openttd
19:01:15 <peter1138> > Can't buy railway vehicle...
19:03:28 <peter1138> Ah, I should've reused 11420 instead of making 11440, oops.
19:18:36 <peter1138> Just get rid of unsigned :p
19:54:41 *** Tirili has quit IRC (Ping timeout: 480 seconds)
20:31:32 <xarick> Bing Chat with GPT-4 can't help me with this question: "powershell get cpu usage when locale is not english"
20:32:56 <bungus> "install WSL and htop"
20:38:35 <xarick> > Get-Counter -Counter 'Processor(*)% Processor Time' | Select-Object -ExpandProperty CounterSamples
20:39:00 <xarick> but it's not named Processor(*)% Processor Time here, so it fails
20:39:27 <xarick> I don't even know how's it named locally
20:45:03 <xarick> Stack Exchange, I'm afraid to ask anything there
20:47:50 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:54:28 <bungus> xarick: does `Get-Counter -ListSet * | Sort-Object CounterSetName | Format-Table CounterSetName` list all the names, like processor, in your locale?
20:55:31 <peter1138> Can you just override the current locale for your command?
21:01:08 <goddess_ishtar> _jgr_: to me this is literally the reason I play the game, since "a collection of point-to-point links" is utterly trivial and boring
21:01:08 <goddess_ishtar> so cargodist is definitely mandatory for me :p
21:01:08 <goddess_ishtar> and I hate the idea of cargo deciding it wants to go to some specific spot that I don't have connected to my network, so cargodist is good for that too
21:28:25 <talltyler> bungus: No, the plaza industry generates passengers (and also accepts them, although this has no effect on production)
21:28:57 <jfs> xarick: I think the problem might be that the text generator has stripped out some backslashes from the counter name, try this instead:
21:28:57 <jfs> `Get-Counter "\Processor(*)\% Processor Time" | Select-Object -ExpandProperty CounterSamples`
21:30:37 <xarick> jfs: Get-Counter : The specified object was not found on the computer.
21:34:48 <jfs> xarick: okay then you do this to list all of the counter sets that exist:
21:34:48 <jfs> `Get-Counter -ListSet * | Format-Table CounterSetName,Paths`
21:34:48 <jfs> and to see what counters are in a set in detail:
21:34:48 <jfs> `Get-Counter -ListSet * | Where-Object CounterSetName -eq "Processor" | Select-Object -ExpandProperty Paths`
21:35:44 <jfs> (btw those commands can be abbreviated a bunch, I'm just writing them out to the full "formally correct" spelling here for the sake of example)
21:36:53 <jfs> (in regular use for myself, I'd write the second as `get-counter -listset *|where countersetname -eq processor|% paths`)
21:38:27 <xarick> the first line posted a whole bunch of lines, most of them in portuguese
21:39:12 <jfs> you need to actually read through the output of the first command to find the name of the counterset you want to query
21:39:23 <bungus> thats what i said ๐ฉ
21:39:48 <jfs> then replace the `"Processor"` name in the second line with the counterset name you found from reading through the first command's output
21:40:43 <xarick> I see, is this the only way? What if I run my ps1 file on somebody's else system which may not be english?
21:41:18 <jfs> yeah that's really weird and I don't know why the counters don't seem to have a GUID or other immutable ID
21:41:21 <_glx_> it's not PS fault, it's the system itself
21:42:36 <xarick> I think I found the name!
21:42:36 <xarick> `Processo {\Processo(*)\% de tempo do processador, \Processo(*)\% tempo de utilizador, \Process...`
21:50:02 <jfs> meanwhile, I found a method that might be more portable:
21:50:02 <jfs> `Get-WmiObject Win32_PerfFormattedData_PerfOS_Processor|Format-Table Name,PercentProcessorTime`
21:52:01 *** Wormnest has joined #openttd
21:58:25 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:01:56 *** tokai|noir has joined #openttd
22:01:56 *** ChanServ sets mode: +v tokai|noir
22:02:41 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:08:56 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:19:51 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:20:18 <_zephyris> Are nightlies not nightly any more? The version listed is stuck back at 2023-10-29 19:03 UTC...
22:37:51 <peter1138> Universal law of Minecraft. It's night time when you connect...
22:40:40 <Rubidium> _zephyris: looks like the nightlies are built, but the website isn't updated. The latest.yaml seems to be having the right information on the CDN, so I'm also wondering what's going awry with the website
22:42:27 <peter1138> Is it possibly related to Cloudflare going tits up the other day?
22:44:34 <Rubidium> I hope truebrain or _glx_ might have a clue how to solve this
22:45:50 <peter1138> Seems to be trying to do something with pr11347... no idea.
22:47:21 <_glx_> website workflow is failing for a week now
22:47:50 <peter1138> Not the same error for a week though.
22:48:08 <truebrain> The first was Cloudflare outage
22:48:17 <truebrain> The rest is because a PR upload broke
22:48:24 <truebrain> Most likely during that outage
22:48:32 <truebrain> So files that should be there aren't
22:50:19 <_glx_> might be me cancelling a run at the wrong moment
22:50:36 <truebrain> Needs manual intervention; will do that tomorrow evening
22:51:58 <truebrain> Basically, the metadata says there should he a folder that isn't there. That should he impossible ofc
22:52:20 <truebrain> _glx_: That should be impossible
22:52:46 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:53:52 <truebrain> These metadata files are updated in a single upload command. Ofc you could cancel that one .. but that it tricky. And is done in another repo ๐
22:55:15 <truebrain> So yeah, related to Cloudflares outage ๐
22:57:05 <peter1138> We're not in Andy's MBP anymore...
23:37:48 *** Tirili has quit IRC (Quit: Leaving)
continue to next day โต