Back to Home / #openttd / 2020 / 05 / Prev Day | Next Day
#openttd IRC Logs for 2020-05-22

---Logopened Fri May 22 00:00:14 2020
00:05-!-keoz [~keikoz@2a01:e35:2fd5:51e0:f8f9:92f8:8ddf:16d3] has joined #openttd
00:05-!-keoz is "Grmph" on #openttd
01:00-!-snail_UES_ [] has quit [Quit: snail_UES_]
01:13-!-Wormnest [] has quit [Ping timeout: 480 seconds]
01:57<Speeder>yeah, the pathc I compiled is buggy regarding sprinf
01:57<Speeder>whenever it invokes sprintf is outputs mojibake
01:58-!-andythenorth [] has joined #openttd
01:58-!-andythenorth is "andythenorth" on #openttd
02:08-!-sla_ro|master [] has joined #openttd
02:08-!-sla_ro|master is "slamaster" on #sla #openttd
02:21-!-gnu_jj [] has quit []
02:34-!-gnu_jj [] has joined #openttd
02:34-!-gnu_jj is "jj" on #ceph-devel #ceph #openttd
02:53-!-Samu [] has joined #openttd
02:53-!-Samu is "realname" on #openttd
03:06-!-nielsm [] has quit [Ping timeout: 480 seconds]
03:13-!-suomi [~oftc-webi@2601:646:9581:8700:bdcd:3586:91bb:d987] has quit [Remote host closed the connection]
03:46-!-nielsm [] has joined #openttd
03:46-!-nielsm is "Niels Martin Hansen" on #openttd
03:57-!-iSoSyS [~iSoSyS@2001:818:e851:d900:7285:c2ff:fedd:1e5b] has joined #openttd
03:57-!-iSoSyS is "realname" on #/r/openttd #openttd
04:01-!-iSoSyS [~iSoSyS@2001:818:e851:d900:7285:c2ff:fedd:1e5b] has quit []
04:03-!-y2kboy23 [~y2kboy23@2600:8800:6003:9900:106c:4471:7cf:7503] has quit [Ping timeout: 481 seconds]
04:05-!-cHawk- [~cHawk@] has quit [Ping timeout: 480 seconds]
04:17-!-D-HUND [~debdog@2a00:79c0:672:b600:7a24:afff:fe8a:d04d] has quit [Quit: Initiating getting-the-hell-out-of-here maneuver!]
04:19-!-debdog [~debdog@2a00:79c0:672:b600:7a24:afff:fe8a:d04d] has joined #openttd
04:19-!-debdog is "Wowbagger" on #openttd
04:30-!-y2kboy23 [] has joined #openttd
04:30-!-y2kboy23 is "Got ZNC?" on #openttd
04:58-!-cHawk- [] has joined #openttd
04:58-!-cHawk- is "realname" on #debian #openttd #debian-next
04:59-!-gelignite [] has joined #openttd
04:59-!-gelignite is "realname" on #openttd
05:03-!-cHawk- [] has quit [Quit: Leaving]
05:17-!-y2kboy23 [] has quit [Quit: ZNC -]
05:17-!-y2kboy23 [~y2kboy23@2600:8800:6003:9900:edea:4c55:6ffa:fd32] has joined #openttd
05:17-!-y2kboy23 is "Got ZNC?" on #openttd
05:18-!-cHawk [] has joined #openttd
05:18-!-cHawk is "realname" on #debian-offtopic #debian-next #openttd #debian
05:26<andythenorth>128 cargos per game? o_O
05:27<@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
05:27<@planetmaker>do we play thickhead? I feel like
05:28<@planetmaker>or simply blacklist as those are pointless anyway?
05:46-!-WormnestAndroid [] has quit [Remote host closed the connection]
05:46-!-WormnestAndroid [] has joined #openttd
05:46-!-WormnestAndroid is "WormnestAndroid" on #openttd
06:20-!-gelignite [] has quit [Quit: Stay safe! Stay at home! Stop the chain reaction!]
06:48-!-sla_ro|master [] has quit []
07:04<Heiki>trying to compile the latest master version on Debian testing fails with the following error:
07:04<Heiki>/usr/bin/ld: strgen_base.o: in function `StringReader::HandleString(char*)':
07:04<Heiki>strgen_base.cpp:(.text+0x1132): undefined reference to `Utf8Decode(unsigned int*, char const*)'
07:11<+michi_cc>Heiki: Which compiler is used on Debian testing?
07:11<Heiki>gcc version 9.3.0 (Debian 9.3.0-13)
07:11<+michi_cc>At least the compilers we use on our CI do not complain.
07:13<+michi_cc>Okay, our CI uses gcc 6.something, not sure what changed there tough.
07:14<@planetmaker>I can confirm the same with GCC10 on Fedora
07:15<+michi_cc>I'm totally not sure how the compiler arrives at unsigned int for the first param though.
07:16<+michi_cc>Utf8Decode takes a WChar, which is now defined as a char32_t that is a distinct fundamental type.
07:16<@planetmaker>though... granted... @Heiki did you try a new ./configure and make?
07:16<Heiki>I did
07:16<nielsm>michi_cc: WChar = uint32_t ?
07:16<nielsm>that's unsigned int isn't it
07:16<@planetmaker>interesting. Because after make clean; ./configure; make
07:16<@planetmaker>the issue vanished for me
07:17<+michi_cc>nielsm: Not anymore. It is char32_t now.
07:17<+michi_cc>And that is spcifically defined as a distinct type, even if it has the same size as an uint.
07:17<Heiki>didn’t try “make clean” though, trying now
07:32<Heiki>oh, “make clean” did it
07:42<andythenorth>256 cargos per game? o_O
07:43<+michi_cc>Okay, we have a dep check failure somewhere, but we're getting cmake soon(TM) anyway.
07:44<LordAro>michi_cc: sounds like an old object file wasn't rebuilt when building with a new compiler?
07:44<LordAro>not sure there's anything we can do about that
07:44<LordAro>compiler ABI change or something
07:47<+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 :)
07:51<LordAro>michi_cc: hmm, maybe
07:52<LordAro>i didn't think makedepends (or whatever we use) listed system headers
07:56<@planetmaker>LordAro, no, it's not to do with compiler. I didn't update my compiler... just my OpenTTD
07:57<@planetmaker>so must be somewhere between ~1.10.0 and now
08:01<@planetmaker>can someone please approve my bananas PR to blacklist the remaining newgrfs by brianium?
08:03<@planetmaker>I deleted his account from LDAP as by GDPR request
08:04<@planetmaker>I will notify him of the deleting as soon as the bananas PR is approved and merged
08:04-!-Yexo [~Yexo@2001:985:a5dd:1:79da:2565:d93d:24a0] has joined #openttd
08:04-!-mode/#openttd [+o Yexo] by ChanServ
08:04-!-Yexo is "realname" on @#openttd
08:20-!-frosch123 [] has joined #openttd
08:20-!-frosch123 is "frosch" on #openttd
08:24<FLHerne>Just to confirm, the "km/h" display speed is different from the internal km/h-ish value?
08:24<FLHerne>Seems to be, looking at the source
08:28<_dp_>FLHerne, think so too
08:30<_dp_>especially since it's km/h-ish mp/h :p
08:34-!-Speeder [~Speeder@2804:14d:ac83:4f59:e4e2:36f7:412e:5a5c] has quit [Ping timeout: 480 seconds]
08:48<FLHerne>supermop_Home: Have you seen ?
08:48<FLHerne>("OpenGFX+ Stations"). Looks really neat
08:49<FLHerne>supermop_Home: Oh, you commented on it, nvm :p
08:54<supermop_Home>FLHerne i first drew those sprites to get included in it!
08:54<supermop_Home>i pm'd a much of modified / improved sprites to the author but never heard bac
08:55<supermop_Home>so figured could at least try to get the improved sprites into opengfx
08:56<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
08:59<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
09:09<@planetmaker>maybe you can send him patches?
09:12<supermop_Home>planetmaker i sent just a modified version of his sprite sheet before so could just be dropped in and recompiled
09:12<supermop_Home>and never heard back, so I assume they do not want any input
09:14<FLHerne>Or they don't read forum PMs :p
09:15<FLHerne>Might be worth posting in the thread itself, that way anyone else can try them out at least
09:18-!-gelignite [~gelignite@] has joined #openttd
09:18-!-gelignite is "realname" on #openttd
09:21-!-snail_UES_ [] has joined #openttd
09:21-!-snail_UES_ is "Jacopo Coletto" on #openttd
10:30-!-Speeder [~Speeder@2804:14d:ac83:4f59:3127:d070:5951:bcc8] has joined #openttd
10:30-!-Speeder is "realname" on #openttd
10:34<Speeder>my net is back
10:34<Speeder>also my map making efforts are advancing :D
10:35<frosch123>are you speeding along?
10:58<andythenorth>512 cargos per game? o_O
11:13<supermop_Home>only if they are slightly different varieties of cheese
11:14<frosch123>@calc 26*26
11:14<@DorpsGek>frosch123: 676
11:14<frosch123>andythenorth: 2 letter abbreviations work, but colors run out
11:18-!-sla_ro|master [] has joined #openttd
11:18-!-sla_ro|master is "slamaster" on @#sla #openttd
11:21<andythenorth>I wondered about option for alternating stripes of colour?
11:21<andythenorth>like css gradients :P
11:22-!-Speeder_ [~Speeder@2804:14d:ac83:4f59:3127:d070:5951:bcc8] has joined #openttd
11:22-!-Speeder_ is "realname" on #openttd
11:25-!-cHawk [] has quit [Ping timeout: 480 seconds]
11:26-!-Speeder [~Speeder@2804:14d:ac83:4f59:3127:d070:5951:bcc8] has quit [Ping timeout: 480 seconds]
11:26-!-Wormnest [] has joined #openttd
11:26-!-Wormnest is "Wormnest" on #openttd
11:29-!-sla_ro|master [] has quit []
11:33-!-Progman [] has joined #openttd
11:33-!-Progman is "Peter Henschel" on #openttd
11:36-!-sla_ro|master [] has joined #openttd
11:36-!-sla_ro|master is "slamaster" on @#sla #openttd
11:51-!-iSoSyS [~iSoSyS@2001:818:e851:d900:7285:c2ff:fedd:1e5b] has joined #openttd
11:51-!-iSoSyS is "realname" on #/r/openttd #openttd
11:54-!-Flygon [~Flygon@2001:44b8:411e:4e00:ccb2:3511:2d4c:92f6] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
11:56-!-glx [] has joined #openttd
11:56-!-mode/#openttd [+v glx] by ChanServ
11:56-!-glx is "Loïc GUILLOUX" on +#openttd
12:35-!-Speeder [~Speeder@2804:14d:ac83:4f59:3127:d070:5951:bcc8] has joined #openttd
12:35-!-Speeder is "realname" on #openttd
12:36-!-Speeder_ [~Speeder@2804:14d:ac83:4f59:3127:d070:5951:bcc8] has quit [Ping timeout: 480 seconds]
12:48<andythenorth>with 512 cargos, it might be nice to play a slightly bigger map
12:48<andythenorth>maybe 1024x1024?
12:54-!-Wormnest [] has quit [Ping timeout: 480 seconds]
12:57<Speeder>512 cargos how???
13:00-!-gelignite [~gelignite@] has quit [Quit: Stay safe! Stay at home! Stop the chain reaction!]
13:01-!-WormnestAndroid [] has quit [Ping timeout: 480 seconds]
13:01-!-WormnestAndroid [~WormnestA@2607:fb90:6a92:d865:0:11:18ab:ab01] has joined #openttd
13:01-!-WormnestAndroid is "WormnestAndroid" on #openttd
13:02<andythenorth>in my imagination
13:17<FLHerne>andythenorth: Your imagination is silly and wrong :p
13:26-!-super_spooky [~rwblair@] has quit [Read error: Connection reset by peer]
14:00<andythenorth>ok just 128 cargos then?
14:08<FLHerne>(1 MIIILLION cargos?)
14:09<frosch123>FLHerne: we had some inflation, you should rather ask for 1 billion
14:12<andythenorth>I have so many essential cargos to feature :D
14:12-!-gelignite [~gelignite@] has joined #openttd
14:12-!-gelignite is "realname" on #openttd
14:13-!-cHawk [~cHawk@] has joined #openttd
14:13-!-cHawk is "realname" on #debian #openttd #debian-next #debian-offtopic
14:24<DorpsGek_III>[OpenTTD/OpenTTD] FLHerne opened issue #8166: Crash when loading stupid roadtypes newgrf
14:25<FLHerne>^I broke it
14:28<andythenorth>ha :)
14:28<andythenorth>Well Played
14:29-!-Wolf01 [] has joined #openttd
14:29-!-Wolf01 is "Wolf01" on #openttd
14:30<DorpsGek_III>[OpenTTD/OpenTTD] FLHerne commented on issue #8166: Crash when loading stupid roadtypes newgrf
15:08<+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?
15:15<DorpsGek_III>[OpenTTD/OpenTTD] michicc approved pull request #7896: Feature: Push-buttons on storybook pages
15:16<+michi_cc>Anybody wanting to look at #8091, or is that a nope and I should close it?
15:17<+glx>I think removing Town::cargo_accepted is the way to go as there seems to be many issues with it
15:18<+michi_cc>I'll have to readd it if I ever update YACD again (in the next century or so :)
15:19<DorpsGek_III>[OpenTTD/OpenTTD] glx22 commented on issue #8166: Crash when loading stupid roadtypes newgrf
15:23<FLHerne>glx: I know, that's why I filed the bug :p
15:26<FLHerne>michi_cc: Seems like a good idea in principle to me
15:34<_dp_>michi_cc, glx pr doesn't solve desync issues
15:34<_dp_>also probaly has savegame compatibility issues
15:34<+glx>of course it's just a rewrite of the loading issue
15:35<+michi_cc>It's still a necessary part in case cargo_accepted is to be kept.
15:35<_dp_>I don't see any reason for it to be kept tbh
15:36<_dp_>it's supposedly a performance optimization that wastes more resources than it saves
15:36<+glx>anyway when debugging it, I noticed the loaded data rarely match the recalculated data
15:37<+glx>so caching cargo_accepted doesn't feel that safe at all
15:38<_dp_>you can probably make it work with all the patches from
15:39<+glx>oh and yes, I think my version is wrong on the saving side
15:40-!-Knogle [] has joined #openttd
15:40-!-Knogle is "..." on #openttd.notice #openttd
15:40<+glx>hmm no, as there's a savegame bump it's ok
15:41<+glx>but for a backport without bump it needs to be adapted
15:42<FLHerne>Can someone with Windows check that is broken there? :p
15:42<FLHerne>I probably should have updated the pyinstaller `nmlc.spec` also
15:42<_dp_>glx, I don't think it's possible to backport without bump, you just have half the space you need for the data
15:42<FLHerne>But I don't have a Windows box, and the exe crashes in Wine because of a missing interface
15:43<FLHerne>So no way to test either the potential issue or any fix for it
15:44<+glx>_dp_: in the backport version, always save 32 bit, and discard on load if savegame until current version
15:44<_dp_>glx, well, yeah but then you lose half of the cargo bits...
15:45<_dp_>I guess it better than losing all of them but...
15:45<+glx>FLHerne: yes the check fails because setup never ran before
15:46<+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)
15:46<FLHerne>glx: Hm? The release action runs `python --version` before pyinstaller
15:47<+glx>FLHerne: but not build
15:47<FLHerne>glx: But we don't update the version in build_py
15:48<_dp_>glx, if it's recalculated it solves nothing so no point backporting
15:48<frosch123>glx: master has still the same savegame version as 1.10
15:48<frosch123>so bump is possible
15:48<FLHerne>glx: It's done on import of
15:48<FLHerne>Which is possibly a bad idea for other reasons, but whatever
15:48<+glx>FLHerne: testing is broken, but release works
15:49<+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.
15:49<+michi_cc>The biggest part of that diff is #8118, which is marked for backport anyway.
15:50<+michi_cc>As such, a concurrent savegame bump shouldn't pose a problem.
15:51<FLHerne>glx: You mean the Github `testing` action? I don't think I care in that case ;-)
15:51<+glx>yes the action
15:51<+glx>though I could fix it
15:51<FLHerne>I guess the right thing to do would be to call get_and_write_version() from nmlc.spec
15:52<+glx>not sure it's possible, I don't understand how pyinstaller hooks work
15:53<+glx>anyway the issue is the native lib is not built
15:57<+glx>or the cache, can't remember exactly, but the standalone exe in releases should work
15:58-!-iSoSyS [~iSoSyS@2001:818:e851:d900:7285:c2ff:fedd:1e5b] has quit []
16:00<FLHerne>I notice none of the editor highlighting files are installed anywhere
16:00<FLHerne>That would be a cross-platfor pain though
16:01-!-Knogle [] has quit []
16:04<frosch123>are they even up-to-date?
16:06<DorpsGek_III>[OpenTTD/OpenTTD] FLHerne commented on issue #8166: Crash when loading stupid roadtypes newgrf
16:06<FLHerne>frosch123: They're generated
16:07<+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)
16:07<FLHerne>Well, there are scripts to generate them, which seem to work, but the packaging/build process doesn't run them :-/
16:08<+glx>you mean build-dist.bat ?
16:09<FLHerne>^ was about the editor files
16:10<FLHerne>But now you mention it, why doesn't the testing/release thing use that?
16:11<+glx>for release build is always ran in the previous steps for wheels
16:12<FLHerne>glx: I think the release build is broken, in that #136 doesn't fix it
16:12<FLHerne>Nothing stops being packaged
16:13<FLHerne>Oh, but I guess the windows installer zipthingy will never be a git repo
16:13<FLHerne>So it won't matter
16:14<nielsm>michi_cc: would you be okay with just squashing the entire storybook buttons PR into a single commit?
16:18<+michi_cc>nielsm: Yeah, I wouldn't really know where to split it up anyway.
16:21<+glx>FLHerne: it's ok, the git detection is based on the location of the " path = os.path.dirname(os.path.dirname(os.path.realpath(__file__)))" and this file is actually in a temp dir in case of standalone exe
16:22<FLHerne>Yeah, I realized, two lines up :p
16:22<DorpsGek_III>[OpenTTD/OpenTTD] nielsmh merged pull request #7896: Feature: Push-buttons on storybook pages
16:32-!-SpComb [] has quit [Ping timeout: 480 seconds]
16:34-!-WormnestAndroid [~WormnestA@2607:fb90:6a92:d865:0:11:18ab:ab01] has quit [Ping timeout: 480 seconds]
16:34<DorpsGek_III>[OpenTTD/OpenTTD] michicc updated pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
16:36-!-WormnestAndroid [] has joined #openttd
16:36-!-WormnestAndroid is "WormnestAndroid" on #openttd
16:36-!-SpComb [] has joined #openttd
16:36-!-SpComb is "Tero Marttila" on #oftc #bitlbee #openttd
16:37<FLHerne>michi_cc: fwiw, I'm a little skeptical that the competitive Squirrel implementation actually works properly, given who wrote it :p
16:39<+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.
16:39-!-Wormnest [] has joined #openttd
16:39-!-Wormnest is "Wormnest" on #openttd
16:40<FLHerne>Hm, ok
16:41<@Yexo>I don't think a 3% improvement (as per last comment in that PR) makes it worth to add an extra API
16:42<+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.
16:43<+michi_cc>Time for pathfinder runs can amount to game-years.
16:43<@Yexo>For badly tweaked pathfinder code, yes
16:43<+glx>and in this case it's just another native storage like lists
16:44<+glx>but pathfinding is still done in squirrel
16:44<@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.
16:45<@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
16:45<+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.
16:46<@Yexo>A path that loops around itself? No
16:46<@Yexo>But it does handle trying to cross existing bridges correctly
17:03<DorpsGek_III>[OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
17:06<DorpsGek_III>[OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
17:16<DorpsGek_III>[OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
17:17-!-andythenorth [] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:25<Samu>Yexo, you have a water pathfinder?
17:25<@Yexo>Yes. It needs a bit more testing, I'll publish it next week
17:26<Samu>oh cool
17:27<@Yexo> if you want to play with it
17:31<@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).
17:32<@Yexo>That alone should be a 4x performance in pathfinder times
17:32<@Yexo>Additionally, pending some performance testing, perhaps the number of operations per tick could be increased as well
17:34<frosch123>did we ever try to run ais in parallel?
17:34<nielsm>that... might actually work
17:34<frosch123>(sqvm + thread for each ai company)
17:34<@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)
17:34<nielsm>as long as you serialize on command execution
17:34<frosch123>i can't remember whether it was not possible, or whether it was too difficult with old ottd stuff
17:35<@Yexo>That idea crossed my mind as well to try, I can't remember it being tried
17:35<Samu>the code is only 200 lines
17:35<frosch123>nielsm: ais suspend for commands, they are synchronised with network state anyway
17:35<@Yexo>On a hunch I'd say the same as nielsm, should work with serialization on commands
17:35<frosch123>unless command test-runs do weird stuff
17:36<frosch123>but then we can mutex that part
17:36<@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
17:36<nielsm>I think you'll need to serialize all command execution and test-flight
17:36<@Yexo>There might very well be edge-cases I've missed, hence: needs more testing
17:36-!-WormnestAndroid [] has quit [Read error: Connection reset by peer]
17:37-!-WormnestAndroid [] has joined #openttd
17:37-!-WormnestAndroid is "WormnestAndroid" on #openttd
17:37<nielsm>so you don't risk one command running in test while another is executing
17:37<@Yexo>command test-runs definitely do weird stuff, and those don't suspend AIs right now
17:37<@Yexo>even running two commands in test mode is problematic I think
17:38<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
17:38<frosch123>so, sq is fine with multitheading, but ottd is not :p
17:39<frosch123>so, next question is, how many ottd api functions need mutex
17:39<nielsm>actually giving each AI its own thread might also be a chance of simplifying the pause/resume stuff
17:39<frosch123>test-runs are one, but do test-runs disrupt simple map accessors?
17:39<nielsm>I assume it was only written that way originally to support systems that don't have multithreading
17:39<nielsm>but now threading is a requirement for building ottd
17:41<nielsm>hm, I don't think there's anything that will write to the map and revert
17:41<frosch123>hmm, yeah, i guess the full ottd api needs mutex
17:41<frosch123>nielsm: for vehicles we do that a lot :)
17:41<nielsm>something like a reader-writer mutex perhaps
17:41<frosch123>not sure about other commands
17:42<frosch123>yep shared_mutex should catch most cases
17:42<@Yexo>It's not just map changes. There are too many globals :(
17:42<nielsm>yeah wrapping various data sets in multiple-reader-single-writer mutexes basically
17:42<@Yexo>current_company might be problematic in several places
17:43<nielsm>owh yea
17:43<frosch123>he, current_company is a good one :)
17:43<nielsm>TLS time?
17:43<Samu>got no time to test today, will take a look tomorrow
17:44<frosch123>if you mean thread-local-stage, too hackish
17:44-!-Samu [] has quit [Quit: Leaving]
17:44<frosch123>rather have a _current_company within the aicontroller
17:44<frosch123>there probably even is one
17:44<@Yexo>There is one
17:45<@Yexo>CmdBuildAircraft sets v->owner to _current_company (first example I found)
17:45<frosch123>yes, all command stuff is exclusive lock
17:45<milek7>huh, threading is required now?
17:45<frosch123>milek7: c++11 is required
17:45<nielsm>commands really should carry an "executing company" parameter
17:47<frosch123>nielsm: 373 occurences of _current_company, give it a try?
17:48<@Yexo>Quite a bit, but it should be a mechanical change, not complicated at all
17:53<@Yexo>Time for bed
17:54-!-Yexo [~Yexo@2001:985:a5dd:1:79da:2565:d93d:24a0] has quit [Quit: Leaving]
17:57-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
17:58-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
18:00<DorpsGek_III>[OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
18:02<DorpsGek_III>[OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
18:03-!-keoz [~keikoz@2a01:e35:2fd5:51e0:f8f9:92f8:8ddf:16d3] has quit [Ping timeout: 480 seconds]
18:07<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
18:08<FLHerne>Or just duplicates
18:09<DorpsGek_III>[OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
18:12<DorpsGek_III>[OpenTTD/OpenTTD] michicc commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
18:26<DorpsGek_III>[OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
18:27<DorpsGek_III>[OpenTTD/OpenTTD] Yexo commented on pull request #8091: Add: [Script] Native priority queue; useful e.g. for pathfinders.
18:37-!-nielsm [] has quit [Ping timeout: 480 seconds]
18:40-!-Progman [] has quit [Remote host closed the connection]
18:51-!-gelignite [~gelignite@] has quit [Quit: Stay safe! Stay at home! Stop the chain reaction!]
19:12-!-sla_ro|master [] has quit []
20:56-!-heffer [] has quit [Remote host closed the connection]
20:59-!-Extrems` [] has joined #openttd
20:59-!-Extrems` is "" on #openttd
20:59-!-heffer [] has joined #openttd
20:59-!-heffer is "Felix Kaechele" on #openttd
21:00-!-Extrems [] has quit [Remote host closed the connection]
21:00-!-Extrems` is now known as Extrems
21:08-!-heffer [] has quit [Remote host closed the connection]
21:13-!-heffer [] has joined #openttd
21:13-!-heffer is "Felix Kaechele" on #openttd
22:27-!-tokai|noir [] has joined #openttd
22:27-!-tokai|noir is "Christian Rosentreter" on #openttd
22:27-!-mode/#openttd [+v tokai|noir] by ChanServ
22:33-!-tokai [] has quit [Ping timeout: 480 seconds]
22:35-!-Flygon [~Flygon@2001:44b8:411e:4e00:607d:4c58:d259:3b78] has joined #openttd
22:35-!-Flygon is "Flygon" on #openttd
22:43-!-glx [] has quit []
22:55-!-D-HUND [~debdog@2a00:79c0:637:e600:7a24:afff:fe8a:d04d] has joined #openttd
22:55-!-D-HUND is "Wowbagger" on #openttd
22:58-!-debdog [~debdog@2a00:79c0:672:b600:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
23:17-!-WormnestAndroid [] has quit [Read error: Connection reset by peer]
23:18-!-WormnestAndroid [] has joined #openttd
23:18-!-WormnestAndroid is "WormnestAndroid" on #openttd
23:31-!-WormnestAndroid [] has quit [Read error: Connection reset by peer]
23:31-!-keoz [~keikoz@2a01:e35:2fd5:51e0:f8f9:92f8:8ddf:16d3] has joined #openttd
23:31-!-keoz is "Grmph" on #openttd
23:31-!-WormnestAndroid [~WormnestA@2607:fb90:6a8c:1f25:0:1e:cf1a:7101] has joined #openttd
23:31-!-WormnestAndroid is "WormnestAndroid" on #openttd
23:40-!-WormnestAndroid [~WormnestA@2607:fb90:6a8c:1f25:0:1e:cf1a:7101] has quit [Ping timeout: 480 seconds]
23:40-!-WormnestAndroid [] has joined #openttd
23:40-!-WormnestAndroid is "WormnestAndroid" on #openttd
23:43-!-gnu_jj [] has quit []
23:43-!-gnu_jj [] has joined #openttd
23:43-!-gnu_jj is "jj" on #ceph #openttd #ceph-devel
---Logclosed Sat May 23 00:00:15 2020