Times are UTC Toggle Colours
00:40:10 *** Wormnest has joined #openttd 00:51:01 *** gelignite has quit IRC 01:53:04 *** Flygon has joined #openttd 02:26:55 *** tokai has joined #openttd 02:26:55 *** ChanServ sets mode: +v tokai 02:33:49 *** tokai|noir has quit IRC 02:38:05 *** suomi has joined #openttd 02:41:27 <suomi> I'm sure it's been asked before, but has any thought gone into making priority signals? Priorities are nice to have on your lines, but, having to implement them by adding a bunch of useless track is pretty unappealing 02:56:19 *** D-HUND has joined #openttd 02:59:46 *** debdog has quit IRC 03:23:18 *** Wormnest has quit IRC 03:34:41 *** Wormnest has joined #openttd 03:52:21 *** glx has quit IRC 04:05:28 *** keoz has joined #openttd 05:00:37 *** snail_UES_ has quit IRC 05:13:59 *** Wormnest has quit IRC 05:57:40 <Speeder> yeah, the pathc I compiled is buggy regarding sprinf 05:57:49 <Speeder> whenever it invokes sprintf is outputs mojibake 05:58:49 *** andythenorth has joined #openttd 06:01:31 <andythenorth> yo 06:08:45 *** sla_ro|master has joined #openttd 06:21:39 *** gnu_jj has quit IRC 06:34:49 *** gnu_jj has joined #openttd 06:53:39 *** Samu has joined #openttd 06:56:14 <Samu> hi 07:06:16 *** nielsm has quit IRC 07:13:56 *** suomi has quit IRC 07:46:10 *** nielsm has joined #openttd 07:57:50 *** iSoSyS has joined #openttd 08:01:31 *** iSoSyS has quit IRC 08:03:50 *** y2kboy23 has quit IRC 08:05:34 *** cHawk- has quit IRC 08:17:37 *** D-HUND has quit IRC 08:19:12 *** debdog has joined #openttd 08:30:10 *** y2kboy23 has joined #openttd 08:58:19 *** cHawk- has joined #openttd 08:59:44 *** gelignite has joined #openttd 09:03:51 *** cHawk- has quit IRC 09:17:46 *** y2kboy23 has quit IRC 09:17:58 *** y2kboy23 has joined #openttd 09:18:47 *** cHawk has joined #openttd 09:26:55 <andythenorth> 128 cargos per game? o_O 09:27:39 <planetmaker> moin. Great joy.... this nice guy who uploaded the newgrf(s) Yoshi complained about now writes an e-mail to request immediate removal of his 2 remaining newgrfs 09:27:46 <planetmaker> do we play thickhead? I feel like 09:28:30 <planetmaker> or simply blacklist as those are pointless anyway? 09:46:29 *** WormnestAndroid has quit IRC 09:46:42 *** WormnestAndroid has joined #openttd 10:20:18 *** gelignite has quit IRC 10:48:35 *** sla_ro|master has quit IRC 11:04:32 <Heiki> trying to compile the latest master version on Debian testing fails with the following error: 11:04:35 <Heiki> /usr/bin/ld: strgen_base.o: in function `StringReader::HandleString(char*)': 11:04:37 <Heiki> strgen_base.cpp:(.text+0x1132): undefined reference to `Utf8Decode(unsigned int*, char const*)' 11:11:20 <michi_cc> Heiki: Which compiler is used on Debian testing? 11:11:46 <Heiki> gcc version 9.3.0 (Debian 9.3.0-13) 11:11:50 <michi_cc> At least the compilers we use on our CI do not complain. 11:13:06 <michi_cc> Okay, our CI uses gcc 6.something, not sure what changed there tough. 11:14:12 <planetmaker> I can confirm the same with GCC10 on Fedora 11:15:09 <michi_cc> I'm totally not sure how the compiler arrives at unsigned int for the first param though. 11:16:33 <michi_cc> Utf8Decode takes a WChar, which is now defined as a char32_t that is a distinct fundamental type. 11:16:34 <planetmaker> though... granted... @Heiki did you try a new ./configure and make? 11:16:43 <Heiki> I did 11:16:48 <nielsm> michi_cc: WChar = uint32_t ? 11:16:54 <nielsm> that's unsigned int isn't it 11:16:56 <planetmaker> interesting. Because after make clean; ./configure; make 11:16:59 <planetmaker> the issue vanished for me 11:17:00 <michi_cc> nielsm: Not anymore. It is char32_t now. 11:17:29 <michi_cc> And that is spcifically defined as a distinct type, even if it has the same size as an uint. 11:17:46 <Heiki> didn’t try “make clean” though, trying now 11:32:51 <Heiki> oh, “make clean” did it 11:42:52 <andythenorth> 256 cargos per game? o_O 11:43:13 <michi_cc> Okay, we have a dep check failure somewhere, but we're getting cmake soon(TM) anyway. 11:44:27 <LordAro> michi_cc: sounds like an old object file wasn't rebuilt when building with a new compiler? 11:44:30 <LordAro> not sure there's anything we can do about that 11:44:45 <LordAro> compiler ABI change or something 11:47:04 <michi_cc> LordAro: It should have though, as the header which defines WChar did change. I'm assume here that it was the checkout that was updated last, not debian :) 11:51:54 <LordAro> michi_cc: hmm, maybe 11:52:06 <LordAro> i didn't think makedepends (or whatever we use) listed system headers 11:56:39 <planetmaker> LordAro, no, it's not to do with compiler. I didn't update my compiler... just my OpenTTD 11:57:04 <planetmaker> so must be somewhere between ~1.10.0 and now 11:57:20 <LordAro> weird 12:01:58 <planetmaker> can someone please approve my bananas PR to blacklist the remaining newgrfs by brianium? 12:03:47 <planetmaker> I deleted his account from LDAP as by GDPR request 12:04:20 <planetmaker> I will notify him of the deleting as soon as the bananas PR is approved and merged 12:04:44 *** Yexo has joined #openttd 12:04:44 *** ChanServ sets mode: +o Yexo 12:20:37 *** frosch123 has joined #openttd 12:24:00 <FLHerne> Just to confirm, the "km/h" display speed is different from the internal km/h-ish value? 12:24:16 <FLHerne> Seems to be, looking at the source 12:28:46 <_dp_> FLHerne, think so too 12:30:11 <_dp_> especially since it's km/h-ish mp/h :p 12:34:53 *** Speeder has quit IRC 12:36:38 <supermop_Home> yo 12:42:34 <FLHerne> oy 12:48:10 <FLHerne> supermop_Home: Have you seen https://www.tt-forums.net/viewtopic.php?f=67&t=86995 ? 12:48:31 <FLHerne> ("OpenGFX+ Stations"). Looks really neat 12:49:26 <FLHerne> supermop_Home: Oh, you commented on it, nvm :p 12:54:12 <supermop_Home> FLHerne i first drew those sprites to get included in it! 12:54:45 <supermop_Home> i pm'd a much of modified / improved sprites to the author but never heard bac 12:55:17 <supermop_Home> so figured could at least try to get the improved sprites into opengfx 12:56:38 <supermop_Home> honestly the shortcomings of the maglev station never bothered me much before because i never played with the vanilla maglevs. But once I could use the station as a generic modern station i wished it had a bit more love 12:59:16 <supermop_Home> I guess it's GPL so i could just release my own version, but 1) stations are a pain, and 2) see no reason to fragment things more 13:09:11 <planetmaker> maybe you can send him patches? 13:12:26 <supermop_Home> planetmaker i sent just a modified version of his sprite sheet before so could just be dropped in and recompiled 13:12:43 <supermop_Home> and never heard back, so I assume they do not want any input 13:14:55 <FLHerne> Or they don't read forum PMs :p 13:15:18 <FLHerne> Might be worth posting in the thread itself, that way anyone else can try them out at least 13:18:39 *** gelignite has joined #openttd 13:21:30 *** snail_UES_ has joined #openttd 14:30:30 *** Speeder has joined #openttd 14:34:04 <Speeder> yay 14:34:05 <Speeder> my net is back 14:34:19 <Speeder> also my map making efforts are advancing :D 14:35:39 <frosch123> are you speeding along? 14:58:13 <andythenorth> 512 cargos per game? o_O 15:13:01 <supermop_Home> only if they are slightly different varieties of cheese 15:14:01 <frosch123> @calc 26*26 15:14:01 <DorpsGek> frosch123: 676 15:14:12 <frosch123> andythenorth: 2 letter abbreviations work, but colors run out 15:18:47 *** sla_ro|master has joined #openttd 15:21:42 <andythenorth> I wondered about option for alternating stripes of colour? 15:21:46 <andythenorth> like css gradients :P 15:22:23 *** Speeder_ has joined #openttd 15:25:36 *** cHawk has quit IRC 15:26:24 *** Speeder has quit IRC 15:26:43 *** Wormnest has joined #openttd 15:29:15 *** sla_ro|master has quit IRC 15:33:58 *** Progman has joined #openttd 15:36:16 *** sla_ro|master has joined #openttd 15:51:46 *** iSoSyS has joined #openttd 15:54:03 *** Flygon has quit IRC 15:56:26 *** glx has joined #openttd 15:56:26 *** ChanServ sets mode: +v glx 16:35:11 *** Speeder has joined #openttd 16:36:53 *** Speeder_ has quit IRC 16:48:30 <andythenorth> with 512 cargos, it might be nice to play a slightly bigger map 16:48:37 <andythenorth> maybe 1024x1024? 16:54:23 *** Wormnest has quit IRC 16:57:25 <Speeder> 512 cargos how??? 17:00:35 *** gelignite has quit IRC 17:01:49 *** WormnestAndroid has quit IRC 17:01:54 *** WormnestAndroid has joined #openttd 17:02:04 <andythenorth> in my imagination 17:17:48 <FLHerne> andythenorth: Your imagination is silly and wrong :p 17:26:38 *** super_spooky has quit IRC 18:00:01 <andythenorth> ok just 128 cargos then? 18:07:43 <FLHerne> nonono 18:08:05 <FLHerne> (1 MIIILLION cargos?) 18:08:25 <andythenorth> 8^8 18:09:11 <frosch123> FLHerne: we had some inflation, you should rather ask for 1 billion 18:12:31 <andythenorth> I have so many essential cargos to feature :D 18:12:41 *** gelignite has joined #openttd 18:13:07 *** cHawk has joined #openttd 18:24:51 <DorpsGek_III> [OpenTTD/OpenTTD] FLHerne opened issue #8166: Crash when loading stupid roadtypes newgrf https://git.io/Jf2HG 18:25:01 <FLHerne> ^I broke it 18:28:13 <andythenorth> ha :) 18:28:15 <andythenorth> Well Played 18:29:38 *** Wolf01 has joined #openttd 18:30:11 <DorpsGek_III> [OpenTTD/OpenTTD] FLHerne commented on issue #8166: Crash when loading stupid roadtypes newgrf https://git.io/Jf2HG 18:59:42 <Wolf01> Interesting 19:08:33 <michi_cc> glx: You had an alternate PR for #8157 which to me looks better. Do you still want to post that or is the tendency to remove Town::cargo_accepted altogether? 19:15:22 <DorpsGek_III> [OpenTTD/OpenTTD] michicc approved pull request #7896: Feature: Push-buttons on storybook pages https://git.io/Jf2Q1 19:16:27 <michi_cc> Anybody wanting to look at #8091, or is that a nope and I should close it? 19:17:11 <glx> I think removing Town::cargo_accepted is the way to go as there seems to be many issues with it 19:18:12 <michi_cc> I'll have to readd it if I ever update YACD again (in the next century or so :) 19:19:59 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8166: Crash when loading stupid roadtypes newgrf https://git.io/Jf2HG 19:23:51 <FLHerne> glx: I know, that's why I filed the bug :p 19:26:26 <FLHerne> michi_cc: Seems like a good idea in principle to me 19:34:29 <_dp_> michi_cc, glx pr doesn't solve desync issues 19:34:45 <_dp_> also probaly has savegame compatibility issues 19:34:59 <glx> of course it's just a rewrite of the loading issue 19:35:05 <michi_cc> It's still a necessary part in case cargo_accepted is to be kept. 19:35:39 <_dp_> I don't see any reason for it to be kept tbh 19:36:01 <_dp_> it's supposedly a performance optimization that wastes more resources than it saves 19:36:18 <glx> anyway when debugging it, I noticed the loaded data rarely match the recalculated data 19:37:14 <glx> so caching cargo_accepted doesn't feel that safe at all 19:38:04 <_dp_> you can probably make it work with all the patches from https://github.com/OpenTTD/OpenTTD/issues/7603#issuecomment-628031816 19:39:02 <glx> oh and yes, I think my version is wrong on the saving side 19:40:16 *** Knogle has joined #openttd 19:40:45 <glx> hmm no, as there's a savegame bump it's ok 19:41:26 <glx> but for a backport without bump it needs to be adapted 19:42:20 <FLHerne> Can someone with Windows check that https://github.com/OpenTTD/nml/pull/136 is broken there? :p 19:42:40 <FLHerne> I probably should have updated the pyinstaller `nmlc.spec` also 19:42:57 <_dp_> glx, I don't think it's possible to backport without bump, you just have half the space you need for the data 19:42:57 <FLHerne> But I don't have a Windows box, and the exe crashes in Wine because of a missing interface 19:43:16 <FLHerne> So no way to test either the potential issue or any fix for it 19:44:08 <glx> _dp_: in the backport version, always save 32 bit, and discard on load if savegame until current version 19:44:38 <_dp_> glx, well, yeah but then you lose half of the cargo bits... 19:45:01 <_dp_> I guess it better than losing all of them but... 19:45:07 <glx> FLHerne: yes the check fails because setup never ran before 19:46:12 <glx> as the data is ignored on load and recalculated anyway it's not an issue, and it's still compatible with previous version (ie broken) 19:46:46 <FLHerne> glx: Hm? The release action runs `python setup.py --version` before pyinstaller 19:47:04 <glx> FLHerne: but not setup.py build 19:47:41 <FLHerne> glx: But we don't update the version in build_py 19:48:01 <_dp_> glx, if it's recalculated it solves nothing so no point backporting 19:48:14 <frosch123> glx: master has still the same savegame version as 1.10 19:48:18 <frosch123> so bump is possible 19:48:34 <FLHerne> glx: It's done on import of setup.py 19:48:44 <FLHerne> Which is possibly a bad idea for other reasons, but whatever 19:48:47 <glx> FLHerne: testing is broken, but release works 19:49:03 <michi_cc> According to "git diff upstream/release/1.10 upstream/master -- src/saveload" I don't see anything that changed the on-disk savegame data. 19:49:23 <michi_cc> The biggest part of that diff is #8118, which is marked for backport anyway. 19:50:26 <michi_cc> As such, a concurrent savegame bump shouldn't pose a problem. 19:51:06 <FLHerne> glx: You mean the Github `testing` action? I don't think I care in that case ;-) 19:51:15 <glx> yes the action 19:51:36 <glx> though I could fix it 19:51:38 <FLHerne> I guess the right thing to do would be to call get_and_write_version() from nmlc.spec 19:52:16 <glx> not sure it's possible, I don't understand how pyinstaller hooks work 19:53:07 <glx> anyway the issue is the native lib is not built 19:57:14 <glx> or the cache, can't remember exactly, but the standalone exe in releases should work 19:58:00 *** iSoSyS has quit IRC 20:00:39 <FLHerne> I notice none of the editor highlighting files are installed anywhere 20:00:49 <FLHerne> That would be a cross-platfor pain though 20:01:06 *** Knogle has quit IRC 20:04:32 <frosch123> are they even up-to-date? 20:06:23 <DorpsGek_III> [OpenTTD/OpenTTD] FLHerne commented on issue #8166: Crash when loading stupid roadtypes newgrf https://git.io/Jf2HG 20:06:35 <FLHerne> frosch123: They're generated 20:07:00 <glx> FLHerne: version is always updated in setup.py, but generated tables (parser and lexer) are only created in build step (or first run which is an issue for standalone exe, or install in read only location, but it's ok for releases as we build before packaging) 20:07:43 <FLHerne> Well, there are scripts to generate them, which seem to work, but the packaging/build process doesn't run them :-/ 20:08:37 <glx> you mean build-dist.bat ? 20:09:26 <FLHerne> ^ was about the editor files 20:09:31 <glx> ha 20:10:02 <FLHerne> But now you mention it, why doesn't the testing/release thing use that? 20:11:41 <glx> for release build is always ran in the previous steps for wheels 20:12:28 <FLHerne> glx: I think the release build is broken, in that #136 doesn't fix it 20:12:39 <FLHerne> Nothing stops version_update.py being packaged 20:13:11 <FLHerne> Oh, but I guess the windows installer zipthingy will never be a git repo 20:13:14 <FLHerne> So it won't matter 20:14:15 <nielsm> michi_cc: would you be okay with just squashing the entire storybook buttons PR into a single commit? 20:18:31 <michi_cc> nielsm: Yeah, I wouldn't really know where to split it up anyway. 20:21:30 <glx> FLHerne: it's ok, the git detection is based on the location of the version_update.py " path = os.path.dirname" target="_blank">os.path.dirname(os.path.dirname" target="_blank">os.path.dirname(os.path.realpath(__file__)))" and this file is actually in a temp dir in case of standalone exe 20:22:20 <FLHerne> Yeah, I realized, two lines up :p 20:22:58 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7896: Feature: Push-buttons on storybook pages https://git.io/JepYW 20:32:46 *** SpComb has quit IRC 20:34:09 *** WormnestAndroid has quit IRC 20:34:32 <DorpsGek_III> [OpenTTD/OpenTTD] michicc updated pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/JfUub 20:36:02 *** WormnestAndroid has joined #openttd 20:36:09 *** SpComb has joined #openttd 20:37:01 <FLHerne> michi_cc: fwiw, I'm a little skeptical that the competitive Squirrel implementation actually works properly, given who wrote it :p 20:39:46 <michi_cc> FLHerne: It actually does, at least in the specific context of the pathfinder lib. I've run several of Samu's old testcases during coding the PR, and did check the resulting paths. 20:39:50 *** Wormnest has joined #openttd 20:40:26 <FLHerne> Hm, ok 20:41:28 <Yexo> I don't think a 3% improvement (as per last comment in that PR) makes it worth to add an extra API 20:42:46 <michi_cc> Pathfinder speed is the biggest obstacle to good AI performance especially on larger maps, I think this is one area where every bit helps. 20:43:23 <michi_cc> Time for pathfinder runs can amount to game-years. 20:43:39 <Yexo> For badly tweaked pathfinder code, yes 20:43:48 <glx> and in this case it's just another native storage like lists 20:44:16 <glx> but pathfinding is still done in squirrel 20:44:19 <Yexo> I have an water-pathfinder that takes about 20% of the ticks compared to Samu's last version I've seen, ie 80% faster. 20:45:04 <Yexo> I think there are many gains to be had within the pathfinders themselves, which should be explored first before we get to micro-optimizing the priority queue code 20:45:39 <michi_cc> Does it handle canal bridges correctly (including crossing/not crossing)? I think that was Samu's sticking point which he was trying to get right. 20:46:08 <Yexo> A path that loops around itself? No 20:46:18 <Yexo> But it does handle trying to cross existing bridges correctly 21:03:21 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2F4 21:06:59 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2Fa 21:16:40 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2FD 21:17:03 *** andythenorth has quit IRC 21:25:00 <Samu> Yexo, you have a water pathfinder? 21:25:24 <Yexo> Yes. It needs a bit more testing, I'll publish it next week 21:26:06 <Samu> oh cool 21:27:08 <Yexo> https://paste.ubuntu.com/p/nXxsJzJnDw/ if you want to play with it 21:31:57 <Yexo> michi_cc: as far as AI performance: by default AIs only run every 4th gametick (_settings_game.difficulty.competitor_speed is 2 by default). If the speed is such a concern, I think we should look into removing this setting (or at least defaulting it to 4). 21:32:13 <Yexo> That alone should be a 4x performance in pathfinder times 21:32:33 <Yexo> Additionally, pending some performance testing, perhaps the number of operations per tick could be increased as well 21:34:03 <frosch123> did we ever try to run ais in parallel? 21:34:27 <nielsm> that... might actually work 21:34:28 <frosch123> (sqvm + thread for each ai company) 21:34:39 <Yexo> I think any increases are good, but imho a 3% performance increase is currently not worth an extra API class. I think there are better opportunities that give much higher performance gain (especially for cases like pathfinding, where tweaking of pathfinder values can help immensely) 21:34:42 <nielsm> as long as you serialize on command execution 21:34:52 <frosch123> i can't remember whether it was not possible, or whether it was too difficult with old ottd stuff 21:35:07 <Yexo> That idea crossed my mind as well to try, I can't remember it being tried 21:35:22 <Samu> the code is only 200 lines 21:35:28 <frosch123> nielsm: ais suspend for commands, they are synchronised with network state anyway 21:35:29 <Yexo> On a hunch I'd say the same as nielsm, should work with serialization on commands 21:35:55 <frosch123> unless command test-runs do weird stuff 21:36:05 <frosch123> but then we can mutex that part 21:36:35 <Yexo> Samu: My implementation handles bridges in a simpler way: The pathfinder basically returns the tile _after_ the bridge as the end tile, which gets rid of a bunch of special cases since now the distance is always >1 even for the smallest size bridge 21:36:47 <nielsm> I think you'll need to serialize all command execution and test-flight 21:36:58 <Yexo> There might very well be edge-cases I've missed, hence: needs more testing 21:36:59 *** WormnestAndroid has quit IRC 21:37:17 *** WormnestAndroid has joined #openttd 21:37:21 <nielsm> so you don't risk one command running in test while another is executing 21:37:32 <Yexo> command test-runs definitely do weird stuff, and those don't suspend AIs right now 21:37:45 <Yexo> even running two commands in test mode is problematic I think 21:38:13 <nielsm> yeah, basically every time an AI tests or executes a command it needs to post to a queue and wait for a result, and the main thread executes that queue 21:38:44 <frosch123> so, sq is fine with multitheading, but ottd is not :p 21:39:09 <frosch123> so, next question is, how many ottd api functions need mutex 21:39:13 <nielsm> actually giving each AI its own thread might also be a chance of simplifying the pause/resume stuff 21:39:23 <frosch123> test-runs are one, but do test-runs disrupt simple map accessors? 21:39:34 <nielsm> I assume it was only written that way originally to support systems that don't have multithreading 21:39:44 <nielsm> but now threading is a requirement for building ottd 21:41:05 <nielsm> hm, I don't think there's anything that will write to the map and revert 21:41:05 <frosch123> hmm, yeah, i guess the full ottd api needs mutex 21:41:38 <frosch123> nielsm: for vehicles we do that a lot :) 21:41:40 <nielsm> something like a reader-writer mutex perhaps 21:41:44 <frosch123> not sure about other commands 21:42:22 <frosch123> yep shared_mutex should catch most cases 21:42:33 <Yexo> It's not just map changes. There are too many globals :( 21:42:43 <nielsm> yeah wrapping various data sets in multiple-reader-single-writer mutexes basically 21:42:44 <Yexo> current_company might be problematic in several places 21:43:07 <nielsm> owh yea 21:43:07 <frosch123> he, current_company is a good one :) 21:43:16 <nielsm> TLS time? 21:43:47 <Samu> got no time to test today, will take a look tomorrow 21:43:57 <Samu> thx 21:44:02 <Samu> btw 21:44:03 <Samu> cyas 21:44:06 <frosch123> if you mean thread-local-stage, too hackish 21:44:10 *** Samu has quit IRC 21:44:19 <frosch123> rather have a _current_company within the aicontroller 21:44:26 <frosch123> there probably even is one 21:44:32 <Yexo> There is one 21:45:11 <Yexo> CmdBuildAircraft sets v->owner to _current_company (first example I found) 21:45:38 <frosch123> yes, all command stuff is exclusive lock 21:45:40 <milek7> huh, threading is required now? 21:45:51 <frosch123> milek7: c++11 is required 21:45:59 <nielsm> commands really should carry an "executing company" parameter 21:47:37 <frosch123> nielsm: 373 occurences of _current_company, give it a try? 21:48:43 <Yexo> Quite a bit, but it should be a mechanical change, not complicated at all 21:53:58 <Yexo> Time for bed 21:53:59 <Yexo> GN 21:54:06 *** Yexo has quit IRC 21:57:52 *** Wolf01 has quit IRC 21:58:36 *** frosch123 has quit IRC 22:00:15 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2bi 22:02:08 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2bM 22:03:06 *** keoz has quit IRC 22:07:54 <FLHerne> michi_cc: The ideal behaviour for pathfinders would be to avoid duplicate entries, but set the priority to the minimum of the old and new entries 22:08:30 <FLHerne> Or just duplicates 22:09:37 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2bA 22:12:14 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2Nv 22:26:50 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2Ng 22:27:47 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders. https://git.io/Jf2Na 22:37:51 *** nielsm has quit IRC 22:40:46 *** Progman has quit IRC 22:51:02 *** gelignite has quit IRC 23:12:43 *** sla_ro|master has quit IRC