IRC logs for #openttd on OFTC at 2020-06-01
⏴ go to previous day
00:00:35 <frosch123> "CATS" was the planned station set by V/elyon
00:01:23 <frosch123> anyway, no code available
00:03:21 <frosch123> not sure whether you were around when V started with newgrf
00:03:37 <frosch123> but V made various vehicle, industry and landscape grfs
00:03:46 <Yexo> Not sure either. He was a community member already for sure
00:03:48 <frosch123> until eaten by factorio campaign
00:04:10 <Yexo> Yes, I recognized his name on the factorio blog a while ago
00:04:35 <frosch123> this channel encouraged him to apply for the job. so it's our fault :p
00:05:08 <frosch123> it's also our fault, that he uses python to automate stuff
00:05:18 <glx> this channel was a factorio channel for some time ;)
00:05:40 <Yexo> I'm not very surprised that game speaks to many people here
00:05:50 <frosch123> yes, and coop server runs a factorio server instead of ottd nightly :p
00:06:14 <Yexo> You're just tempting me to check that out now :p
00:06:27 <frosch123> no idea whether it is still active
00:06:44 <glx> ok nml stations won't happen soon then :)
00:06:44 <frosch123> but when i still had access to the hypervisor, it usually had that task running :p
00:07:59 <Yexo> nah, I've played my share of factorio. One server isn't going to get me hooked now again
00:11:37 <andythenorth> V453000 is really me
00:11:43 <andythenorth> like in fight club
00:15:57 <milek7> fight club is some movie that everybody is supposed to know?
00:17:29 <frosch123> yes, but i do not know it either
00:17:50 <nielsm> just go look up the spoilers for it
00:18:29 <andythenorth> it's not very good imho
00:18:39 <andythenorth> I started reading the book also, but it's blah blah
00:22:01 <Yexo> sleep is a good plan. Night all
00:25:17 <Speeder_> I was reding some historical documents about Brazil
00:25:26 <Speeder_> and they made me wonder... what would happen if ports accepted Mail as cargo?
00:25:31 <Speeder_> would it break anything?
00:25:56 <DorpsGek_III> [OpenTTD/OpenTTD] InTheMorning commented on pull request #7213: Feature: BFS-based river generator https://git.io/Jf6MT
00:28:17 <Speeder_> and... would it be good idea?
00:28:58 <FLHerne> Base-game oil rigs accepts passengers
00:29:05 <Eddi|zuHause> what a random comment...
00:29:38 <FLHerne> And I think in BSPI and ECS most industries accept some passengers, as 'workers'
00:30:14 <FLHerne> Or was that YETI, not ECS?
00:30:35 <FLHerne> Not, YETI has yeti dudes, and those are different :p
00:32:14 <FLHerne> Eddi|zuHause: Less random than "Cricket wirrless uograde codes"
00:33:25 <Eddi|zuHause> oh yeah, i think i've seent that :p
00:38:16 *** Smedles has joined #openttd
00:44:42 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo dismissed a review for pull request #8178: Simplify code by removing 2 global variables. https://git.io/Jf6Kf
00:44:42 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo updated pull request #8178: Simplify code by removing 2 global variables. https://git.io/Jf6oM
00:46:01 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8178: Simplify code by removing 2 global variables. https://git.io/Jf6Mz
00:55:20 *** Gustavo6046 has joined #openttd
01:09:57 *** Wormnest has joined #openttd
02:16:28 *** Wrench_In_The_Plan has quit IRC
03:09:55 *** Wrench_In_The_Plan has joined #openttd
05:25:18 *** Hobbyboy has joined #openttd
06:13:28 *** Wrench_In_The_Plan has quit IRC
06:43:12 *** WormnestAndroid has quit IRC
06:43:29 *** WormnestAndroid has joined #openttd
07:23:04 *** andythenorth has joined #openttd
09:05:08 *** Progman has joined #openttd
09:05:27 *** sla_ro|master has joined #openttd
09:51:24 *** WormnestAndroid has quit IRC
09:51:38 *** WormnestAndroid has joined #openttd
09:52:54 *** WormnestAndroid has quit IRC
09:53:11 *** WormnestAndroid has joined #openttd
10:24:14 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo opened pull request #8179: Fix #8024: make online content gui more responsive while loading https://git.io/Jf6AX
10:48:39 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8179: Fix #8024: make online content gui more responsive while loading https://git.io/Jf6xP
10:59:15 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo merged pull request #8179: Fix #8024: make online content gui more responsive while loading https://git.io/Jf6AX
11:35:40 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo opened pull request #8180: Fix #8166: don't crash on loading an invalid roadtype newgrf https://git.io/Jf6hI
11:42:41 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo approved pull request #8176: Fix #7970: [Win32] Disable event loop on crash to prevent recursive faults https://git.io/Jf6ha
11:46:55 *** Gadg8eer is now known as bluhignore
11:47:45 *** Gadg8eer has joined #openttd
11:50:48 *** bluhignore has left #openttd
11:56:07 <Gadg8eer> Does anyone here have any knowledge about m4nfo? I need to find "Sprite 112" in my code... "A portion of sprite 112 could not be processed." ...but I'm not sure how to find the pseudosprite in question.
11:58:07 <Yexo> I'd start by looking at the generated nfo code, find sprite 112, then work backwards from there to get to the corresponding m4nfo code
12:08:09 <Gadg8eer> That worked. Thanks!
12:36:39 <DorpsGek_III> [OpenTTD/OpenTTD] michicc approved pull request #8180: Fix #8166: don't crash on loading an invalid roadtype newgrf https://git.io/JfieU
12:44:05 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo merged pull request #8180: Fix #8166: don't crash on loading an invalid roadtype newgrf https://git.io/Jf6hI
12:52:18 <DorpsGek_III> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8179: Fix #8024: make online content gui more responsive while loading https://git.io/Jfie1
13:17:58 *** Smedles has joined #openttd
13:18:22 *** ist5shreawf[m] has quit IRC
13:25:27 *** yur3shmukcik[m] has quit IRC
13:28:38 *** hylshols7qui[m] has quit IRC
13:43:44 *** frosch123 has joined #openttd
13:45:40 <FLHerne> Yexo: Do you know if it's valid for railtypes to not have a label?
13:45:53 <FLHerne> I'm a bit surprised there isn't a check in NML for this
13:46:20 <FLHerne> But if I define a railtype *without* a label, it does seem to at least appear in OTTD
13:47:18 <FLHerne> (the equivalent roadtype crashed until just now, o/c)
13:47:34 <frosch123> the railtype is defined by defining a label
13:47:42 <frosch123> are you sure nml does not insert 0000 or something?
13:48:56 <frosch123> hmm, looks like item id 0..3 default to the original railtypes
13:49:05 <frosch123> so you can change them without defining a label
13:51:20 <frosch123> i don't think this is documented behaviour :p
13:51:38 <FLHerne> So, no-one would complain if i just enforce that label: is set?
13:51:49 <frosch123> i would welcome that :)
14:10:02 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 merged pull request #8176: Fix #7970: [Win32] Disable event loop on crash to prevent recursive faults https://git.io/JfKt6
14:10:02 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 closed pull request #8175: Fix #7970: Recursive faults in Windows post-crash due to event loop input https://git.io/JfoXU
14:10:06 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 closed issue #7970: Crash in crash handler - Assertion failed at line 2981 of window.cpp https://git.io/JvsUh
14:29:00 <Yexo> The way I read that is that it's mandatory to specify a label
14:29:43 <frosch123> yes, i also read it like that
14:30:02 <frosch123> i wonder what we break if we do that :)
14:30:46 <Yexo> From what I can tell the railtype_map is only used for railtype newgrfs
14:32:44 <Yexo> FLHerne: Go for the enforcement, but test some existing railtype newgrfs to make sure those don't break
14:40:02 * andythenorth wonders about shunting
14:40:08 <andythenorth> but with consists of consists
14:40:17 <andythenorth> no arbitrarily combining wagons
14:40:32 * andythenorth never tried the shunting patch
14:40:35 <supermop_Home> shunting is fun
14:40:41 <andythenorth> what does the patch do?
14:40:43 <supermop_Home> takes a long time
14:41:05 <supermop_Home> so its better if you want to see pretty trains shunting around,
14:41:32 <andythenorth> I want to be able to do something like
14:41:40 <supermop_Home> but, like real life you are tempted to use MUs everywhere to save turnaround time
14:41:42 <andythenorth> consist A->B, consist C->B
14:41:52 <andythenorth> then both consists travel combined B->D
14:42:04 <supermop_Home> the patch really struggled with things like that
14:42:14 <andythenorth> I can nearly do it with cdist and transfers
14:42:33 <andythenorth> I don't actually want to see wagons moving around
14:42:38 <andythenorth> it's the flow I want
14:42:48 <andythenorth> but 'refit any available' doesn't work with cdist, so I can't use it
14:47:51 <supermop_Home> it clearly does
14:48:06 <supermop_Home> i don't know why you always are saying that
14:48:37 <andythenorth> because cdist establishes unwanted links
14:49:33 <andythenorth> which can't be cleared, except by demolishing the station, and restablishing the graph
14:49:38 <andythenorth> re-establishing :)
14:50:40 <FLHerne> I'm with supermop_Home on this one
14:50:47 <FLHerne> I use it all the time, it works
14:51:01 <supermop_Home> works for me, use it every game:
14:51:32 <FLHerne> As with all the other features, you can certainly make it *not* work
14:51:57 <andythenorth> I could post screenshots of it not working
14:52:20 <andythenorth> I'm not deliberately being obtuse, I've seen it not work over and over again
14:52:32 <supermop_Home> that route there has been running about 20 game years
14:52:44 <FLHerne> Then you're doing it Wrong™
14:53:15 <andythenorth> it's not a bug, it's the only possible behaviour
14:53:44 <andythenorth> its usually caused by a lost train visiting a station
14:54:06 <FLHerne> andythenorth: Then your problem is not using 'non-stop' orders exclusively
14:54:14 <andythenorth> or having lost trains
14:54:14 <FLHerne> (seriously, why isn't that the default)
14:54:39 <andythenorth> the cause is myriad, anything from a network jam to a badly placed signal
14:55:19 <FLHerne> I'm still very confused about what you think the problem is
14:55:21 <andythenorth> but once the link is up, the choices are either reload an old save, or destroy the station, and re-establish all the cargo links manually (which requires refitting the trains explicitly)
14:55:41 <andythenorth> the problem is specifically cdist adding edges where I don't want an edge
14:56:17 <FLHerne> Then you shouldn't add the edge :p
14:56:20 <andythenorth> it's not a bug, cdist wouldn't work any other way
14:56:40 <andythenorth> not adding the edge would only work if I played entirely isolated point to point networks
14:56:57 <andythenorth> and never fucked up a refit
14:57:13 <andythenorth> and never sent out a train without changing the default refit
14:57:42 <FLHerne> I don't play isolated p2p networks, and am fallible, and I still don't see your problem :P
14:58:21 <andythenorth> I think it's actually solved in JGRPP
14:58:29 <andythenorth> that also needs TM
15:06:40 <supermop_Home> yeah andy i'm having trouble identifying this as a problem
15:07:12 <supermop_Home> i also have large networks, and even the occasional lost train
15:07:43 <supermop_Home> and stations that are major transit points for multiple cargos
15:08:56 <supermop_Home> isolated networks only seems necessary in those cases where you are really trying to make cargo go somewhere it does not want to go?
15:10:06 <supermop_Home> i do see the appeal of breaking up rakes with shunting to make small branch lines nice though
15:35:31 *** supermop_Home has joined #openttd
15:37:25 <andythenorth> once the link is up, the trains get filled with cargo that has no acceptance
15:37:37 <supermop_Home> vehicle dealers seem to want to be too close to the city center
15:37:51 <andythenorth> yeah, I'm fixing that
15:38:34 <supermop_Home> once the city gets big, you can't fund them in the inner suburbs that seem like a natural choice
15:41:10 <JGR_> Andy: Most players stick to single-cargo trains
15:42:18 <JGR_> The per-cargo load/unload types patch is in large part to mitigate that issue though
15:45:15 <andythenorth> supermop_Home I'm going to make it just locate by a road, 'somewhat near a town'
15:45:23 <andythenorth> if I can figure out the location check for that :P
15:47:06 <supermop_Home> in this case i am trying to fund one
16:02:36 *** andythenorth is now known as andy_call
16:02:43 *** andy_call is now known as andythenorth
16:19:41 <DorpsGek_III> [OpenTTD/OpenTTD] newHeiko commented on issue #7496: Crashes on start - malloc(): invalid next size (unsorted) https://git.io/fjqCX
16:22:12 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro reopened issue #7496: Crashes on start - malloc(): invalid next size (unsorted) https://git.io/fjqCX
16:31:07 <andythenorth> modest proposal: explicit cdist
16:31:27 <andythenorth> manually specify the start and end nodes
16:31:57 <andythenorth> let cdist do the rest, on the current model, by forcing values for next hops at intermediate stations
16:32:14 <frosch123> add industry properties for demand and scaling
16:32:19 <andythenorth> extension: let GS specify start and end nodes :P
16:32:52 <andythenorth> sandbox, or scenario mode
16:32:59 <andythenorth> whilst we're there, delete subsidies :P
16:33:10 <frosch123> one property to set how much supply is good, and another to distribute under/over supply
16:33:11 <andythenorth> oops did I go too far again? I always ruin a good proposal :|
16:33:29 <frosch123> subsidies are already deleted for cdist
16:33:41 <andythenorth> frosch123 should this be written down? :P
16:33:54 <frosch123> if it has any substance, then yes
16:33:55 <andythenorth> or shall I forget and discuss it again in 6 months
16:34:01 <frosch123> if it is just random rambling, then no
16:34:08 <andythenorth> I am serious about the idea, but the UI might suck
16:34:20 <andythenorth> and it might be really annoying to play
16:34:27 <andythenorth> is this what simutrans does?
16:34:46 <frosch123> no idea, simutrans gui scares me off after 50 seconds
16:35:36 <andythenorth> this would probably be some kind of station UI thing? 'From this station send [cargo] to destination [station | automatic]'
16:36:18 <andythenorth> as far as I understand cdist, we don't then need to give cargopackets destinations, we just set next hop weights at all the intermediate nodes
16:36:28 <andythenorth> probably the demand algorithm somewhat does it already
16:36:37 <andythenorth> so maybe it just creates highly specific demand
16:38:07 <supermop_Home> "from mine in NW corner, only send coal to powerplant in SE corner, and for mine in SE corner, only send coal to NW corner"
16:42:53 *** virtualrandomnumber has joined #openttd
17:04:33 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 commented on issue #7496: Crashes on start - malloc(): invalid next size (unsorted) https://git.io/fjqCX
17:06:02 <LordAro> we should probably just drop libxdg-basedir, tbh
17:06:02 <frosch123> do we still have known-bugs. txt?
17:06:13 <LordAro> it's basically just an ENV_VAR lookup + fallback
17:07:08 <LordAro> i think blathijs said we were almost(?) the only user of it as well
17:13:15 <frosch123> you can also put it into 3rdparty
17:14:06 <LordAro> it seems like something you would've said
17:21:02 <blathijs> I might have, can't remember though.
17:37:03 *** virtualrandomnumber has quit IRC
17:51:18 *** gelignite has joined #openttd
18:05:35 *** Wrench_In_The_Plan has joined #openttd
18:09:56 <DorpsGek_III> [OpenTTD/OpenTTD] newHeiko commented on issue #7496: Crashes on start - malloc(): invalid next size (unsorted) https://git.io/fjqCX
18:13:49 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #7496: Crashes on start - malloc(): invalid next size (unsorted) https://git.io/fjqCX
18:17:15 <frosch123> haha, just to confirm the theory. the guy who is supposedly maintaining the ottd package, also maintains the libxdg-basedir package
18:17:59 <andythenorth> calls make me hungry
18:27:25 *** sla_ro|master has joined #openttd
18:28:42 *** Wormnest has joined #openttd
18:34:52 <andythenorth> I am going to release Horse soon
18:39:10 <LordAro> or not worth the bother?
18:39:26 <nielsm> there's still the old-macos issue but uh.... yeah "someone" needs to do "something" about it
18:39:50 <LordAro> can we just put a if version > 1.12.6 around it?
18:39:57 <LordAro> is there a runtime check like that?
18:40:17 <nielsm> there is, it's already used in several places
18:40:35 <Yexo> <LordAro> backport #8170 ? <- Yes please
18:40:46 <Yexo> Otherwise it doesn't compile with an up-to-date VS anymore, which can be annoying
18:40:58 <LordAro> nielsm: that'd probably do then, given it's otherwise out of date
18:42:12 <nielsm> some null checks should probably also do it
18:48:32 <Yexo> LordAro: Is #8093 in your list already?
18:52:27 <LordAro> Yexo: afaik, i've got everything that's tagged backport requested
18:52:37 <LordAro> though please do tell me if i've missed anything
18:59:07 <nielsm> I'll make an attempt-fix for the macos 10.12 issue in a moment then, got my old mac booted up again
19:19:59 *** A_Very_Fat_Elf has joined #openttd
19:20:38 *** A_Very_Fat_Elf has quit IRC
19:26:43 <Speeder_> II think I will have to split "goods" somehow
19:26:54 <Speeder_> or allow people to get goods from a port and ship to another port
19:29:58 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #8181: Fix #8066: Try another fallback colourspace if first one fails https://git.io/JfiOv
19:31:39 <LordAro> nielsm: are we sure the crash is due to the pointer being null?
19:31:46 <LordAro> rather than just some invalid value
19:31:53 <andythenorth> Speeder_ what are 'goods' anyway? :)
19:32:33 <nielsm> goods is things produced from livestock, grain, steel, copper, wood, and/or oil
19:32:44 <nielsm> I thought that much was clear?
19:35:40 <Speeder_> well... for example, in default TTD, you cna make "goods" in a printing press.
19:35:55 <Speeder_> Brazil imported, and still imports, lots of these type of "goods"
19:36:18 <Speeder_> at same time Brazil exported, and still exports a little, of clothes and textiles.
19:36:20 <Speeder_> that is also "goods"
19:36:33 <Speeder_> but if I let both remain "goods", people can just take stuff from a port, and put back in the port.
19:37:16 <LordAro> you're trying to apply real life to TTD
19:38:18 <LordAro> nielsm: you say you have an old mac, is it old enough to test your PR?
19:38:19 *** jottyfan has joined #openttd
19:38:26 <LordAro> or shall we just merge it and hope?
19:38:36 <LordAro> i really want to get 1.10.2 done
19:38:59 <Speeder_> LordAro, and what you suggest?
19:39:05 <nielsm> nope, it's running 10.13 and I'm not sure there is any easy way to downgrade
19:39:17 <nielsm> and I don't have any spare disks to make a fresh OS install
19:40:05 <andythenorth> no external USB? :)
19:40:36 <nielsm> nothing free that's also fast enough
19:40:58 <LordAro> fast enough is a relative term :p
19:41:08 <nielsm> and it's not exactly something that can be skipped since it creates the primary surface for the video output
19:41:12 <glx> so only test option is merge and ask affected people to test next nightly ?
19:41:33 <nielsm> which is why I suspect the color_space pointer is invalid
19:41:47 <nielsm> since the only other changes in that PR were how the color_space was obtained
19:42:10 <LordAro> that would follow, i think
19:42:23 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8181: Fix #8066: Try another fallback colourspace if first one fails https://git.io/JfiOu
19:42:39 <nielsm> and I doubt apple's CGColorSpace* functions would return non-null invalid pointers :)
19:43:00 <nielsm> and everything indicates that the pointer does not require an additional "retain"/"add reference" call
19:43:40 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #8181: Fix #8066: Try another fallback colourspace if first one fails https://git.io/JfiOv
19:43:59 <nielsm> has today's nightly been built yet? :D
19:44:15 <nielsm> we should probably ask in the issue for people to test
19:44:25 <LordAro> in a few minutes, i believe
19:44:37 <LordAro> translator commit is 18:45, i think nightly is 19:00 ?
19:45:27 <glx> nightly build start in 15 minute
19:45:48 <nielsm> hm now, in derail valley, do I get the Hazmat 2 or the Military 1 license next
19:47:33 <LordAro> github's got confused about commit order again
19:52:53 <milek7> valve index seems interesting
19:52:59 <milek7> but is it actually possible to buy?
19:58:10 <DorpsGek_III> [OpenTTD/DorpsGek] pyup-bot opened pull request #24: Scheduled monthly dependency update for June https://git.io/Jfi3v
20:01:12 <glx> nightly build started btw
20:05:27 <supermop_Home> perfect weather today
20:18:08 *** Wrench_In_The_Plan has quit IRC
20:19:57 <nielsm> I suppose the nightly is finished now, someone should test it
20:20:30 <nielsm> andythenorth can you verify if the nightly build is no worse than expected? :)
20:21:44 <LordAro> website thinks it's finished
20:23:14 <LordAro> should let the (remaining) 10.12 users know
20:24:04 <andythenorth> nielsm anything in particular I'm looking for?
20:31:39 *** ad5twoknebor[m] has quit IRC
20:31:39 *** cyberjunkie[m] has quit IRC
20:31:40 *** WormnestAndroid has quit IRC
20:31:40 *** mindlesstux6662 has quit IRC
20:43:12 *** blathijs has joined #openttd
20:43:12 *** KenjiE20 has joined #openttd
20:43:12 *** Guest26886 has joined #openttd
20:43:12 *** fonsinchen has joined #openttd
20:43:12 *** m1cr0man has joined #openttd
20:43:12 *** gnu_jj_ has joined #openttd
20:43:12 *** gelignite_ has joined #openttd
20:43:12 *** gooodger has joined #openttd
20:43:12 *** sla_ro|master2 has joined #openttd
20:43:12 *** jottyfan has joined #openttd
20:43:12 *** Wormnest has joined #openttd
20:43:12 *** supermop_Home has joined #openttd
20:43:12 *** frosch123 has joined #openttd
20:43:12 *** Smedles has joined #openttd
20:43:12 *** WormnestAndroid has joined #openttd
20:43:12 *** andythenorth has joined #openttd
20:43:12 *** Hobbyboy has joined #openttd
20:43:12 *** Gustavo6046 has joined #openttd
20:43:12 *** robert[m]1 has joined #openttd
20:43:12 *** julie[m] has joined #openttd
20:43:12 *** ericnoan has joined #openttd
20:43:12 *** FLHerne has joined #openttd
20:43:12 *** Terkhen has joined #openttd
20:43:12 *** ZirconiumX has joined #openttd
20:43:12 *** ad5twoknebor[m] has joined #openttd
20:43:12 *** cyberjunkie[m] has joined #openttd
20:43:12 *** leward[m] has joined #openttd
20:43:12 *** ^Spike^ has joined #openttd
20:43:12 *** Hirundo has joined #openttd
20:43:12 *** charon.oftc.net sets mode: +vo glx Terkhen
20:43:12 *** V453000 has joined #openttd
20:43:12 *** Hazzard has joined #openttd
20:43:12 *** Guest26686 has joined #openttd
20:43:12 *** XeryusTC has joined #openttd
20:43:12 *** Webster has joined #openttd
20:43:12 *** magdalena[m] has joined #openttd
20:43:12 *** dekeract[m] has joined #openttd
20:43:12 *** Heiki[m] has joined #openttd
20:43:12 *** paulus[m] has joined #openttd
20:43:12 *** ciet[m] has joined #openttd
20:43:12 *** grag[m] has joined #openttd
20:43:12 *** lastmikoi has joined #openttd
20:43:12 *** DecapitatedO has joined #openttd
20:43:12 *** tyteen4a03 has joined #openttd
20:43:12 *** grossing has joined #openttd
20:43:12 *** mindlesstux6662 has joined #openttd
20:43:12 *** greeter has joined #openttd
20:43:12 *** Timberwolf has joined #openttd
20:43:12 *** LordAro has joined #openttd
20:43:12 *** michi_cc has joined #openttd
20:43:12 *** tonyfinn[m] has joined #openttd
20:43:12 *** BekJut[m] has joined #openttd
20:43:12 *** joey[m] has joined #openttd
20:43:12 *** y2kboy23 has joined #openttd
20:43:12 *** natalie[m]1 has joined #openttd
20:43:12 *** albert[m] has joined #openttd
20:43:12 *** duckfullstop has joined #openttd
20:43:12 *** Xaroth0 has joined #openttd
20:43:12 *** Speeder_ has joined #openttd
20:43:12 *** patrick[m]1 has joined #openttd
20:43:12 *** Extrems has joined #openttd
20:43:12 *** charon.oftc.net sets mode: +v michi_cc
20:43:12 *** Maarten has joined #openttd
20:43:12 *** Eddi|zuHause has joined #openttd
20:43:12 *** Lejving has joined #openttd
20:43:12 *** dwfreed has joined #openttd
20:43:12 *** rudolfs[m] has joined #openttd
20:43:12 *** menelaos[m] has joined #openttd
20:43:12 *** jeeg[m] has joined #openttd
20:43:12 *** ircer[m] has joined #openttd
20:43:12 *** TrueBrain has joined #openttd
20:43:12 *** TrueBrain_ii has joined #openttd
20:43:12 *** mikegrb has joined #openttd
20:43:12 *** DorpsGek_III has joined #openttd
20:43:14 *** daspork has joined #openttd
20:43:14 *** innocenat_ has joined #openttd
20:43:29 *** ChanServ sets mode: +v Yexo
20:43:29 *** ChanServ sets mode: +v DorpsGek
20:43:43 *** Alkel__U3 has joined #openttd
20:43:51 *** Guest26886 is now known as TinoDidriksen
20:44:42 *** Progman has joined #openttd
20:49:17 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo approved pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfisE
20:51:33 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jfisz
20:59:07 *** andythenorth has joined #openttd
21:13:04 <DorpsGek_III> [OpenTTD/OpenTTD] michicc dismissed a review for pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfisE
21:13:04 <DorpsGek_III> [OpenTTD/OpenTTD] michicc updated pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfUub
21:13:29 <michi_cc> Yexo: Shouldn't have made a suggestion, now you need to re-approve :p
21:13:48 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo approved pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfiGU
21:14:16 <Yexo> Yeah, I understand why it works this way, but I'd prefer a bit more trust and not dismissing an approval on small changes
21:15:29 <michi_cc> Well, a single character change can either be a typo fix, or e.g. break everything if it is like * to /. I don't know how GitHub should distinguish this.
21:16:45 <nielsm> that would require something like waiting for the CI to complete and compare the output to previous run and automatically re-approve if the output is identical
21:17:00 <nielsm> and even then that wouldn't necessarily catch things like malicious doc-changes :P
21:17:25 <Yexo> Ideally it wouldn't: once I approve I approve of the concept, maybe pending small changes. I'd trust the author to make the appropriate last-minute small changes and merge afterwards
21:17:59 <Yexo> Needs more trust, but less approval stamping for trivial updates
21:19:29 <michi_cc> Hmm, something went wrong on that push (or git is lying to me).
21:20:00 <supermop_Home> well after preparing her presentation for the last week, my wifes team sent out a message to cancel all meetings 5 min before she was going to present
21:24:35 <DorpsGek_III> [OpenTTD/OpenTTD] michicc dismissed a review for pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfiGU
21:24:35 <DorpsGek_III> [OpenTTD/OpenTTD] michicc updated pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfUub
21:24:40 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8047: Add: Buttons to select script profile in the AI/GS configuration window https://git.io/JfiGC
21:25:00 <michi_cc> Yexo: Sorry, too many checkouts makes for confused me.
21:25:30 <Yexo> michi_cc: no worries. What changed? Github tells me "No new changes since last review"
21:25:57 <michi_cc> That's interesting. I pushed the wrong thing previously.
21:26:09 <michi_cc> It should tell you lots of things changed.
21:27:49 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo approved pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfiGB
21:28:07 <Yexo> Found the diff now (manually, not sure how github can tell me)
21:28:23 <supermop_Home> LordAro it seems it is more or less company wide
21:28:48 <Yexo> <nielsm> and even then that wouldn't necessarily catch things like malicious doc-changes :P <- ^^ shows how easy it is to sneak not even trivial changes by me if you wanted to
21:29:40 <supermop_Home> my company however seems to be making no particular note of things
21:29:46 <michi_cc> Make change in repo 1, force push from repo 2. Profit!
21:29:49 *** y2kboy23 has joined #openttd
21:29:56 <supermop_Home> except for a personal note from the COO
21:30:25 <nielsm> michi_cc: what would be most impressive is if you accidentally pushed an entirely different project over to an ottd branch
21:31:06 <michi_cc> Well, for that to happen I would have to accidentally also change the remote push url.
21:31:33 <LordAro> would just create a completely separate commit tree
21:31:58 <michi_cc> Fully supported by git, even if not that useful.
21:34:01 <LordAro> linux has 3 root commits, for instance
21:34:59 <milek7> "It's pulled, and it's fine, but there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge"."
21:35:17 <DorpsGek_III> [OpenTTD/OpenTTD] michicc merged pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfUub
21:35:35 <LordAro> Cthulhu merge is love, Cthulhu merge is life
21:40:37 <Speeder_> can a script create an oponent?
21:40:55 <Speeder_> like choose an AI, portrait and HQ city?
21:40:59 <Yexo> GameScript? I don't think so
21:41:16 <Yexo> AI itself can chose HQ, not sure about portrait
21:41:32 <LordAro> don't believe it can do portraiy
21:41:45 <LordAro> can do manager name & gender though
21:43:27 <Yexo> Speeder_: I don't see a good use-case for an AI setting the portrait, but if you have something I'm not opposed to a PR for that
21:44:47 <supermop_Home> AI with machine vision and a fashion sense?
21:47:24 <Yexo> 1.10.2-RC1 to buy a bit more time?
21:47:34 <Yexo> Or is the cause still unclear enough that it can't be fixed soon?
21:48:03 <Yexo> Or just go ahead with 1.10.2 and we can make a 1.10.3 once it's fixed
21:48:46 <LordAro> no real need for RC1, imo
21:48:47 <nielsm> yeah better just go ahead
21:48:56 <LordAro> don't think there's anything we need testing
21:49:06 <nielsm> supporting a minority on an old unsupported-by-vendor OS version is not critical
21:49:12 <LordAro> i should adjust the changelog entry for the macos thing though
21:49:29 <Speeder_> Yexo, I am creating a scenario, and wanted the scenario to create some oponents for the player
21:49:43 <Speeder_> for example in a historical scenario, spawn historical transport companies
21:50:19 <nielsm> the only way to create AI players programmatically is in a multiplayer server, where an external script could be sending rcon commands
21:50:59 <nielsm> what you can do is have some AIs that start immediately, but stay dormant until the appropriate year has been reached
21:51:11 <nielsm> and the GS can keep them alive by giving them money once in a while
21:53:33 <Yexo> AI settings are saved in the savegame/scenario file. So you can configure how many AIs should start and approximately when they start
21:53:55 <Speeder_> oh, you can define WHEN they start?
21:54:04 <Speeder_> they don't start always in a fixed date after the last one?
21:54:11 <nielsm> although the player can change the AI start offsets (or disabled them entirely) when they haven't started yet
21:54:39 <Yexo> Sure, but a player can disable other settings you make specific for the scenario
21:55:06 <Yexo> I believe a gamescript can impersonate the AI after it has started and change the president name and HQ location
21:56:59 <Yexo> Speeder_: in the AI?Game script configuration window, select an AI slot, click "Configure" at the bottom. You can set settings for that particular AI. The top setting is always the start delay after the previous AI start
21:57:13 <Yexo> this delay is randomized slightly by OpenTTD (unless you specify 0)
21:58:27 <Speeder_> so although in a convoluted way, I can set the dates of each AI
21:59:59 <spnda> inside the python NML code, where can tokens be defined, like 'true' or so and be given a value?
22:20:03 *** gelignite has joined #openttd
22:27:25 <Yexo> I handn't even spotted that yet :o]
22:33:06 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8178: Simplify code by removing 2 global variables. https://git.io/JfinQ
22:38:31 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo updated pull request #8178: Simplify code by removing 2 global variables. https://git.io/Jf6oM
22:39:12 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8178: Simplify code by removing 2 global variables. https://git.io/JficU
22:41:04 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8178: Simplify code by removing 2 global variables. https://git.io/Jfics
22:45:57 <LordAro> there are some PRs that might be worth some thinking about for 1.10.2
22:46:09 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo merged pull request #8178: Simplify code by removing 2 global variables. https://git.io/Jf6oM
22:48:33 <Yexo> I don't think #8157/#8159 is actually the cause of any desyncs. It can be slightly optimized, but the effect of that will be barely noticable (only at start of month). Changes there will be non-obvious, I generally would not backport that
22:50:20 <Yexo> As for #8149: that attempts to fix a minor gui glitch. Don't see a reason to backport that especially if there are any doubts on corner-cases / reason for the old code like you expressed in your last comment
22:51:36 <Yexo> It's also unclear to me if anybody has really tested #8149
22:52:39 <LordAro> i await someone's approval on the various PRs :)
22:55:03 <Yexo> Do you want to keep "Fix #8066: Try another fallback colourspace if first one fails" even though it was confirmed to not fix the issue?
22:57:19 <Yexo> #8163 has "backport requested" label, but I don't see the backport for it?
22:58:07 <LordAro> I thought i removed the '#8066' from the message
22:58:15 *** Wrench_In_The_Plan has joined #openttd
22:58:49 <LordAro> looks like i missed #8156 as well
22:59:30 <LordAro> right yes, it's (obviously) still in the commit message, but the changelog doesn't mention #8066
22:59:39 <LordAro> i don't touch the commit message when backporting
23:01:19 <Yexo> #8165 is missing as well I think
23:01:50 <LordAro> good to see someone else is awake :)
23:17:19 <LordAro> right, last chance to stop me from tagging
23:21:14 <LordAro> fingers crossed the 20.04 build works
23:23:43 *** Lejving has joined #openttd
23:42:54 <_dp_> did you just release 1.10.2 without desync patch? o_O
23:43:25 <glx> some desync fix are included
23:44:21 <_dp_> didn't notice any fix in commits
23:48:22 <FLHerne> _dp_: Discussed above
23:48:33 <FLHerne> <Yexo> I don't think #8157/#8159 is actually the cause of any desyncs. It can be slightly optimized, but the effect of that will be barely noticable (only at start of month). Changes there will be non-obvious, I generally would not backport that
23:49:30 <FLHerne> If you're certain it is, then...eh, 1.10.3 :p
23:49:34 <_dp_> well, if I understood JGR correctly it did cause desyncs in his pp
23:49:54 <_dp_> and I don't why wouldn't it cause them in vanilla
23:52:41 *** Gadg8eer has joined #openttd
continue to next day ⏵