IRC logs for #openttd on OFTC at 2020-05-22
⏴ go to previous day
00:03:50 <Speeder> found out for some reason gpg was refusing to close
00:04:01 <Speeder> now whenever I close the terminal, if I kill gpg, then it resumes working fine
00:13:18 <Speeder> YAY, IT LIVES! I mean, IT COMPILES!
00:15:10 <glx> oh the wiki page needs an update, freetype is not required
00:27:00 <LordAro> Speeder: in general, `patch -p0 -i path/to/patchfile.diff`
00:27:15 <LordAro> or possibly -p1, depending on the patch format
00:29:10 <LordAro> Speeder: you can also quite easily google about how to apply a patch
00:29:26 <LordAro> there's nothing special about OTTD at this point
00:30:16 <Speeder> well... the -i is what I needed
00:30:24 <Speeder> without it, the patcher would freeze
00:33:40 <LordAro> yes, it's waiting for stdin by default
00:33:58 <LordAro> (which often has the appearance of freezing)
01:03:45 <Speeder> so I hit some angry safeguards about sprintf
01:03:57 <Speeder> so what I am supposed to change them for?
01:04:04 <Speeder> (it is a patch, not my code)
01:04:52 <glx> it's very old if it triggers safeguards
01:08:31 <LordAro> i'm surprised it successfully patched at all if it's that old
01:17:49 <Speeder> well, all it does is add console command to import rivers
01:17:58 <Speeder> but when it fails it uses sprinf to write on signs
01:18:02 <Speeder> I dunno the correct way to do that
01:52:20 *** Smedles has joined #openttd
02:40:10 *** Wormnest has joined #openttd
04:26:55 *** ChanServ sets mode: +v tokai
04: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
05:34:41 *** Wormnest has joined #openttd
07:57:40 <Speeder> yeah, the pathc I compiled is buggy regarding sprinf
07:57:49 <Speeder> whenever it invokes sprintf is outputs mojibake
07:58:49 *** andythenorth has joined #openttd
08:08:45 *** sla_ro|master has joined #openttd
10:30:10 *** y2kboy23 has joined #openttd
10:59:44 *** gelignite has joined #openttd
11:17:58 *** y2kboy23 has joined #openttd
11:26:55 <andythenorth> 128 cargos per game? o_O
11: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
11:27:46 <planetmaker> do we play thickhead? I feel like
11:28:30 <planetmaker> or simply blacklist as those are pointless anyway?
11:46:29 *** WormnestAndroid has quit IRC
11:46:42 *** WormnestAndroid has joined #openttd
13:04:32 <Heiki> trying to compile the latest master version on Debian testing fails with the following error:
13:04:35 <Heiki> /usr/bin/ld: strgen_base.o: in function `StringReader::HandleString(char*)':
13:04:37 <Heiki> strgen_base.cpp:(.text+0x1132): undefined reference to `Utf8Decode(unsigned int*, char const*)'
13:11:20 <michi_cc> Heiki: Which compiler is used on Debian testing?
13:11:46 <Heiki> gcc version 9.3.0 (Debian 9.3.0-13)
13:11:50 <michi_cc> At least the compilers we use on our CI do not complain.
13:13:06 <michi_cc> Okay, our CI uses gcc 6.something, not sure what changed there tough.
13:14:12 <planetmaker> I can confirm the same with GCC10 on Fedora
13:15:09 <michi_cc> I'm totally not sure how the compiler arrives at unsigned int for the first param though.
13:16:33 <michi_cc> Utf8Decode takes a WChar, which is now defined as a char32_t that is a distinct fundamental type.
13:16:34 <planetmaker> though... granted... @Heiki did you try a new ./configure and make?
13:16:48 <nielsm> michi_cc: WChar = uint32_t ?
13:16:54 <nielsm> that's unsigned int isn't it
13:16:56 <planetmaker> interesting. Because after make clean; ./configure; make
13:16:59 <planetmaker> the issue vanished for me
13:17:00 <michi_cc> nielsm: Not anymore. It is char32_t now.
13:17:29 <michi_cc> And that is spcifically defined as a distinct type, even if it has the same size as an uint.
13:17:46 <Heiki> didn’t try “make clean” though, trying now
13:32:51 <Heiki> oh, “make clean” did it
13:42:52 <andythenorth> 256 cargos per game? o_O
13:43:13 <michi_cc> Okay, we have a dep check failure somewhere, but we're getting cmake soon(TM) anyway.
13:44:27 <LordAro> michi_cc: sounds like an old object file wasn't rebuilt when building with a new compiler?
13:44:30 <LordAro> not sure there's anything we can do about that
13:44:45 <LordAro> compiler ABI change or something
13: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 :)
13:52:06 <LordAro> i didn't think makedepends (or whatever we use) listed system headers
13:56:39 <planetmaker> LordAro, no, it's not to do with compiler. I didn't update my compiler... just my OpenTTD
13:57:04 <planetmaker> so must be somewhere between ~1.10.0 and now
14:01:58 <planetmaker> can someone please approve my bananas PR to blacklist the remaining newgrfs by brianium?
14:03:47 <planetmaker> I deleted his account from LDAP as by GDPR request
14:04:20 <planetmaker> I will notify him of the deleting as soon as the bananas PR is approved and merged
14:04:44 *** ChanServ sets mode: +o Yexo
14:20:37 *** frosch123 has joined #openttd
14:24:00 <FLHerne> Just to confirm, the "km/h" display speed is different from the internal km/h-ish value?
14:24:16 <FLHerne> Seems to be, looking at the source
14:30:11 <_dp_> especially since it's km/h-ish mp/h :p
14:48:31 <FLHerne> ("OpenGFX+ Stations"). Looks really neat
14:49:26 <FLHerne> supermop_Home: Oh, you commented on it, nvm :p
14:54:12 <supermop_Home> FLHerne i first drew those sprites to get included in it!
14:54:45 <supermop_Home> i pm'd a much of modified / improved sprites to the author but never heard bac
14:55:17 <supermop_Home> so figured could at least try to get the improved sprites into opengfx
14: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
14: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
15:09:11 <planetmaker> maybe you can send him patches?
15:12:26 <supermop_Home> planetmaker i sent just a modified version of his sprite sheet before so could just be dropped in and recompiled
15:12:43 <supermop_Home> and never heard back, so I assume they do not want any input
15:14:54 <FLHerne> Or they don't read forum PMs :p
15:15:18 <FLHerne> Might be worth posting in the thread itself, that way anyone else can try them out at least
15:18:39 *** gelignite has joined #openttd
15:21:30 *** snail_UES_ has joined #openttd
16:30:30 *** Speeder has joined #openttd
16:34:19 <Speeder> also my map making efforts are advancing :D
16:35:39 <frosch123> are you speeding along?
16:58:13 <andythenorth> 512 cargos per game? o_O
17:13:01 <supermop_Home> only if they are slightly different varieties of cheese
17:14:12 <frosch123> andythenorth: 2 letter abbreviations work, but colors run out
17:18:47 *** sla_ro|master has joined #openttd
17:21:42 <andythenorth> I wondered about option for alternating stripes of colour?
17:21:46 <andythenorth> like css gradients :P
17:22:23 *** Speeder_ has joined #openttd
17:26:43 *** Wormnest has joined #openttd
17:33:59 *** Progman has joined #openttd
17:36:16 *** sla_ro|master has joined #openttd
18:35:11 *** Speeder has joined #openttd
18:48:30 <andythenorth> with 512 cargos, it might be nice to play a slightly bigger map
18:48:37 <andythenorth> maybe 1024x1024?
19:01:49 *** WormnestAndroid has quit IRC
19:01:54 *** WormnestAndroid has joined #openttd
19:02:04 <andythenorth> in my imagination
19:17:48 <FLHerne> andythenorth: Your imagination is silly and wrong :p
20:00:01 <andythenorth> ok just 128 cargos then?
20:08:05 <FLHerne> (1 MIIILLION cargos?)
20:09:11 <frosch123> FLHerne: we had some inflation, you should rather ask for 1 billion
20:12:31 <andythenorth> I have so many essential cargos to feature :D
20:12:41 *** gelignite has joined #openttd
21: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?
21:15:22 <DorpsGek_III> [OpenTTD/OpenTTD] michicc approved pull request #7896: Feature: Push-buttons on storybook pages https://git.io/Jf2Q1
21:16:27 <michi_cc> Anybody wanting to look at #8091, or is that a nope and I should close it?
21:17:11 <glx> I think removing Town::cargo_accepted is the way to go as there seems to be many issues with it
21:18:12 <michi_cc> I'll have to readd it if I ever update YACD again (in the next century or so :)
21:23:51 <FLHerne> glx: I know, that's why I filed the bug :p
21:26:26 <FLHerne> michi_cc: Seems like a good idea in principle to me
21:34:29 <_dp_> michi_cc, glx pr doesn't solve desync issues
21:34:45 <_dp_> also probaly has savegame compatibility issues
21:34:59 <glx> of course it's just a rewrite of the loading issue
21:35:05 <michi_cc> It's still a necessary part in case cargo_accepted is to be kept.
21:35:39 <_dp_> I don't see any reason for it to be kept tbh
21:36:01 <_dp_> it's supposedly a performance optimization that wastes more resources than it saves
21:36:18 <glx> anyway when debugging it, I noticed the loaded data rarely match the recalculated data
21:37:14 <glx> so caching cargo_accepted doesn't feel that safe at all
21:39:02 <glx> oh and yes, I think my version is wrong on the saving side
21:40:45 <glx> hmm no, as there's a savegame bump it's ok
21:41:26 <glx> but for a backport without bump it needs to be adapted
21:42:40 <FLHerne> I probably should have updated the pyinstaller `nmlc.spec` also
21: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
21:42:57 <FLHerne> But I don't have a Windows box, and the exe crashes in Wine because of a missing interface
21:43:16 <FLHerne> So no way to test either the potential issue or any fix for it
21:44:08 <glx> _dp_: in the backport version, always save 32 bit, and discard on load if savegame until current version
21:44:38 <_dp_> glx, well, yeah but then you lose half of the cargo bits...
21:45:01 <_dp_> I guess it better than losing all of them but...
21:45:07 <glx> FLHerne: yes the check fails because setup never ran before
21: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)
21:46:46 <FLHerne> glx: Hm? The release action runs `python setup.py --version` before pyinstaller
21:47:04 <glx> FLHerne: but not setup.py build
21:47:41 <FLHerne> glx: But we don't update the version in build_py
21:48:01 <_dp_> glx, if it's recalculated it solves nothing so no point backporting
21:48:15 <frosch123> glx: master has still the same savegame version as 1.10
21:48:18 <frosch123> so bump is possible
21:48:34 <FLHerne> glx: It's done on import of setup.py
21:48:44 <FLHerne> Which is possibly a bad idea for other reasons, but whatever
21:48:47 <glx> FLHerne: testing is broken, but release works
21:49:04 <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.
21:49:23 <michi_cc> The biggest part of that diff is #8118, which is marked for backport anyway.
21:50:26 <michi_cc> As such, a concurrent savegame bump shouldn't pose a problem.
21:51:06 <FLHerne> glx: You mean the Github `testing` action? I don't think I care in that case ;-)
21:51:38 <FLHerne> I guess the right thing to do would be to call get_and_write_version() from nmlc.spec
21:52:16 <glx> not sure it's possible, I don't understand how pyinstaller hooks work
21:53:07 <glx> anyway the issue is the native lib is not built
21:57:14 <glx> or the cache, can't remember exactly, but the standalone exe in releases should work
22:00:39 <FLHerne> I notice none of the editor highlighting files are installed anywhere
22:00:49 <FLHerne> That would be a cross-platfor pain though
22:04:32 <frosch123> are they even up-to-date?
22:06:35 <FLHerne> frosch123: They're generated
22: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)
22:07:43 <FLHerne> Well, there are scripts to generate them, which seem to work, but the packaging/build process doesn't run them :-/
22:08:37 <glx> you mean build-dist.bat ?
22:09:26 <FLHerne> ^ was about the editor files
22:10:02 <FLHerne> But now you mention it, why doesn't the testing/release thing use that?
22:11:41 <glx> for release build is always ran in the previous steps for wheels
22:12:28 <FLHerne> glx: I think the release build is broken, in that #136 doesn't fix it
22:12:39 <FLHerne> Nothing stops version_update.py being packaged
22:13:11 <FLHerne> Oh, but I guess the windows installer zipthingy will never be a git repo
22:14:15 <nielsm> michi_cc: would you be okay with just squashing the entire storybook buttons PR into a single commit?
22:18:31 <michi_cc> nielsm: Yeah, I wouldn't really know where to split it up anyway.
22:21:30 <glx> FLHerne: it's ok, the git detection is based on the location of the version_update.py " 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
22:22:20 <FLHerne> Yeah, I realized, two lines up :p
22:34:09 *** WormnestAndroid has quit IRC
22: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
22:36:02 *** WormnestAndroid has joined #openttd
22:37:01 <FLHerne> michi_cc: fwiw, I'm a little skeptical that the competitive Squirrel implementation actually works properly, given who wrote it :p
22: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.
22:39:50 *** Wormnest has joined #openttd
22: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
22: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.
22:43:23 <michi_cc> Time for pathfinder runs can amount to game-years.
22:43:39 <Yexo> For badly tweaked pathfinder code, yes
22:43:48 <glx> and in this case it's just another native storage like lists
22:44:16 <glx> but pathfinding is still done in squirrel
22: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.
22:45:03 <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
22: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.
22:46:08 <Yexo> A path that loops around itself? No
22:46:18 <Yexo> But it does handle trying to cross existing bridges correctly
23: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
23: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
23: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
23:25:00 <Samu> Yexo, you have a water pathfinder?
23:25:24 <Yexo> Yes. It needs a bit more testing, I'll publish it next week
23: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).
23:32:13 <Yexo> That alone should be a 4x performance in pathfinder times
23:32:33 <Yexo> Additionally, pending some performance testing, perhaps the number of operations per tick could be increased as well
23:34:03 <frosch123> did we ever try to run ais in parallel?
23:34:27 <nielsm> that... might actually work
23:34:28 <frosch123> (sqvm + thread for each ai company)
23: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)
23:34:42 <nielsm> as long as you serialize on command execution
23:34:52 <frosch123> i can't remember whether it was not possible, or whether it was too difficult with old ottd stuff
23:35:07 <Yexo> That idea crossed my mind as well to try, I can't remember it being tried
23:35:22 <Samu> the code is only 200 lines
23:35:28 <frosch123> nielsm: ais suspend for commands, they are synchronised with network state anyway
23:35:29 <Yexo> On a hunch I'd say the same as nielsm, should work with serialization on commands
23:35:55 <frosch123> unless command test-runs do weird stuff
23:36:05 <frosch123> but then we can mutex that part
23: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
23:36:47 <nielsm> I think you'll need to serialize all command execution and test-flight
23:36:58 <Yexo> There might very well be edge-cases I've missed, hence: needs more testing
23:37:00 *** WormnestAndroid has quit IRC
23:37:17 *** WormnestAndroid has joined #openttd
23:37:21 <nielsm> so you don't risk one command running in test while another is executing
23:37:32 <Yexo> command test-runs definitely do weird stuff, and those don't suspend AIs right now
23:37:45 <Yexo> even running two commands in test mode is problematic I think
23:38:14 <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
23:38:44 <frosch123> so, sq is fine with multitheading, but ottd is not :p
23:39:09 <frosch123> so, next question is, how many ottd api functions need mutex
23:39:13 <nielsm> actually giving each AI its own thread might also be a chance of simplifying the pause/resume stuff
23:39:23 <frosch123> test-runs are one, but do test-runs disrupt simple map accessors?
23:39:34 <nielsm> I assume it was only written that way originally to support systems that don't have multithreading
23:39:44 <nielsm> but now threading is a requirement for building ottd
23:41:05 <nielsm> hm, I don't think there's anything that will write to the map and revert
23:41:05 <frosch123> hmm, yeah, i guess the full ottd api needs mutex
23:41:38 <frosch123> nielsm: for vehicles we do that a lot :)
23:41:40 <nielsm> something like a reader-writer mutex perhaps
23:41:44 <frosch123> not sure about other commands
23:42:22 <frosch123> yep shared_mutex should catch most cases
23:42:33 <Yexo> It's not just map changes. There are too many globals :(
23:42:43 <nielsm> yeah wrapping various data sets in multiple-reader-single-writer mutexes basically
23:42:44 <Yexo> current_company might be problematic in several places
23:43:07 <frosch123> he, current_company is a good one :)
23:43:47 <Samu> got no time to test today, will take a look tomorrow
23:44:06 <frosch123> if you mean thread-local-stage, too hackish
23:44:19 <frosch123> rather have a _current_company within the aicontroller
23:44:26 <frosch123> there probably even is one
23:45:11 <Yexo> CmdBuildAircraft sets v->owner to _current_company (first example I found)
23:45:38 <frosch123> yes, all command stuff is exclusive lock
23:45:40 <milek7> huh, threading is required now?
23:45:51 <frosch123> milek7: c++11 is required
23:45:59 <nielsm> commands really should carry an "executing company" parameter
23:47:37 <frosch123> nielsm: 373 occurences of _current_company, give it a try?
23:48:42 <Yexo> Quite a bit, but it should be a mechanical change, not complicated at all
continue to next day ⏵