Log for #openttd on 22nd May 2020:
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 ?
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
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
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
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
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
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 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 --version` before pyinstaller
19:47:04  <glx> FLHerne: but not 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
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
20:06:35  <FLHerne> frosch123: They're generated
20:07:00  <glx> FLHerne: version is always updated in, 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 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 "    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
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.
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.
21:06:59  <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
21:16:40  <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
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> 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.
22:02:08  <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
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.
22:12:14  <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
22:26:50  <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
22:27:47  <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
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

Powered by YARRSTE version: svn-trunk