IRC logs for #openttd on OFTC at 2020-05-11
⏴ go to previous day
00:00:05 <FLHerne> It worked for me when I tested with `setup.py sdist`
00:00:30 * FLHerne looks at the release actions
00:00:37 <glx> are you sure you got the right file ?
00:01:43 <glx> I see only version_info.py in the bundle
00:02:09 <FLHerne> Ok, no, we're good :D
00:02:44 <FLHerne> When I looked there were just the "Source code (.zip/tar.gz)" entries
00:02:52 <FLHerne> I guess the real bundle hadn't built yet
00:03:09 <FLHerne> nml-0.5.1.tar.gz is correct
00:04:05 * FLHerne stops panicking and puts the kettle on
00:05:40 <FLHerne> The pypi entry says "2 - Pre-Alpha"
00:05:51 <FLHerne> I guess it's still 0.x
00:06:02 <LordAro> that's defined in setup.py
00:08:13 <mcbanhas> Sorry to divert your attention to this matter again, but how do you think STR_ERROR_BRIDGEHEADS_NOT_SAME_HEIGHT should be handled based on the following: https://dpaste.org/LvGz
00:10:21 <LordAro> there's not really anything wrong with it
00:10:28 <LordAro> other than being a bit technical, perhaps
00:10:35 <LordAro> but "bridge head" is a perfectly valid term
00:10:50 <mcbanhas> Well some strings refer to bridge start and end
00:11:14 <mcbanhas> other says just "ends"
00:11:29 <LordAro> "start and end" is correct, as it's referring to when you're drawing a line
00:12:06 <FLHerne> "ends" would be ok, too
00:12:15 <FLHerne> But not "end tiles" like andy suggested earlier
00:12:30 <LordAro> ("bridge ends" rather than "ends of bridge", imo)
00:12:36 <FLHerne> Because bridgeheads can be ramps, so the end *tiles* might be at different levels :P
00:12:57 <FLHerne> Hm, am I subconsciously arguing in favour of that as one word?
00:13:06 <FLHerne> My fingers seem to think that's the right spelling
00:13:24 <LordAro> "bridgehead or bridge-head", says wikipedia
00:13:35 <FLHerne> For consistency with the other one:
00:13:45 <FLHerne> "Start and end must be at the same level" ?
00:14:03 <LordAro> idk, i think i prefer bridgehead to be honest
00:14:09 <FLHerne> "Start and end must be in line" is an existing one and reads ok to me
00:14:59 <FLHerne> "Can't start and end in the same spot" -> "Can't start and end on the same tile" ?
00:15:31 <LordAro> TrueBrain: i notice website#157 is still waiting for you
00:15:38 <LordAro> though you did say "no earlier than"
00:15:44 <FLHerne> And "Bridge would end out of the map" -> "Bridge would end outside the map"
00:16:03 <mcbanhas> FLHerne, going back to that tunnel string from yesterday, do you think "Tunnel openings" is a good alternative to "tunnel entrances"? I dunno why but "entrance" spelled in the plural sounds a bit weird to me.
00:16:24 <LordAro> entrances are entrancing
00:18:07 <FLHerne> I wouldn't mind it, but I think 'entrances' is better
00:18:20 <mcbanhas> STR_RAIL_TOOLBAR_TOOLTIP_BUILD_RAILROAD_TUNNEL :{BLACK}Build railway tunnel:{}Underground passage for rail vehicles. Tunnel entrances can only be placed on sloped land at the same height level. A preview will be displayed if a path is possible. Shift+Click shows estimated cost without purchase
00:18:57 <mcbanhas> also "shown" over "displayed" I think
00:19:02 <FLHerne> Yeah, "portals" could work
00:19:25 <mcbanhas> nah I always associate portals with magic and summoning
00:19:43 *** ChanServ sets mode: +o Yexo
00:19:45 <FLHerne> mcbanhas: Possibly just delete "Underground passage for rail vehicles." ?
00:19:53 <FLHerne> Everyone knows what a tunnel is for
00:20:03 <FLHerne> And the tooltip is quite long anyway
00:20:27 <mcbanhas> FLHerne, I like the little description tbh. I was trying to make sure all building tools would have one.
00:21:02 <FLHerne> mcbanhas: I do like the way it reads, just question if it actually helps the user ;-)
00:21:36 <mcbanhas> Doesn't add anything necessary, no. But I think it's a nice touch.
00:26:09 *** Foveafoxy has joined #openttd
00:26:34 <andythenorth> it's a bit tautological, but eh, let's not die in a ditch over it
00:26:40 *** Foveafoxy is now known as Guest24693
00:26:48 <andythenorth> not sure we need to provide additional definitions for common words
00:27:01 * LordAro paints andythenorth's bikeshed blue
00:27:11 <andythenorth> how is the nuclear pile coming along?
00:27:25 <andythenorth> we still shipping bugs in prod?
00:28:31 <LordAro> _dp_ wanted me to hold off on 1.10.2 release
00:28:35 <FLHerne> andythenorth: nml 0.5.1 is out, and fixes all the bugs anyone's reported recently
00:28:47 <LordAro> see if he can get anywhere with desync debugging overnight
00:29:05 <FLHerne> And a few that no-one reported recently, but glx and I found while doing silly things :P
00:29:08 <andythenorth> so how do I represent natural gas in the game?
00:29:15 <andythenorth> methanol plant that produces like a primary?
00:29:46 <FLHerne> Pipelines as roadtypes?
00:29:52 <andythenorth> gas wells that don't produce, but the methanol plant counts neighbouring gas wells?
00:30:01 <andythenorth> PIPE grf does kinda work
00:30:24 <FLHerne> Apparently there's an industry set with a map-wide electricity counter?
00:30:35 <FLHerne> Someone mentioned it on Reddit, but I forget which
00:40:22 *** gelignite has joined #openttd
00:42:21 <mcbanhas> It's basicaly vanilla+ with a nice feedback loop to it
00:45:33 <mcbanhas> If it ever gets expanded to all biomes it's something I'd like to see integrated as an advanced setting in OpenTTD
00:49:43 <FLHerne> Even things like rotatable and climate-aware airports are grf-only
00:50:15 <FLHerne> (personally I think that's a bit silly, but the argument comes around every year or so, and seems fairly settled)
00:50:31 <andythenorth> hmm 52 chemical cargos
00:50:37 <andythenorth> maybe I delete some stuff
00:50:42 <FLHerne> If you can do it in a grf, the base game doesn't get it
00:51:39 <mcbanhas> Wasn't cargodist a NewGRF before?
00:52:27 <FLHerne> It was a standalone patch for a long time before it was merged
00:52:42 <FLHerne> (and YACD existed before that)
00:54:37 <mcbanhas> I think passenger and mail cargodist are the best things ever
00:56:05 *** mcbanhas_ has joined #openttd
01:02:07 <glx> <FLHerne> If you can do it in a grf, the base game doesn't get it <-- for most things it's mostly because if it's in basegame all base grf must do it in the exact same way, while a newgrf is independant of base grf
01:55:28 <mcbanhas_> Anyone here uses Gnome Meld for handling track changes?
01:58:01 <DorpsGek_III> [OpenTTD/OpenTTD] BastianInuk commented on issue #8038: Fullscreen mode in MacOSX is almost unusable https://git.io/Jv1n7
02:34:00 <_dp_> "Do something of which I have no idea what it is :P"
03:25:03 *** Foveafoxy has joined #openttd
03:25:40 *** Foveafoxy is now known as Guest24703
06:01:55 *** Guest24703 has left #openttd
07:31:01 *** Foveafoxy has joined #openttd
07:31:40 *** Foveafoxy is now known as Guest24721
08:02:46 *** sla_ro|master has joined #openttd
08:22:42 *** Foveafox_ has joined #openttd
08:40:25 *** andythenorth has joined #openttd
10:18:00 <DorpsGek_III> [OpenTTD/nml] matthijskooijman commented on pull request #136: Exclude version update code (fixes #112) and dotfiles from release tarballs. https://git.io/JflOt
10:18:06 <DorpsGek_III> [OpenTTD/OpenTTD] giordy commented on issue #8038: Fullscreen mode in MacOSX is almost unusable https://git.io/Jv1n7
10:49:05 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on issue #8038: Fullscreen mode in MacOSX is almost unusable https://git.io/Jv1n7
10:56:20 *** Foveafoxy has joined #openttd
10:57:00 *** Foveafoxy is now known as Guest24733
11:04:04 <_dp_> but diff is kinda weird, there are some different map tiles but they're mostly farmland %)
11:05:02 *** Smedles has joined #openttd
11:08:18 <andythenorth> 64 cargos might not be enough
11:09:59 *** Smedles has joined #openttd
11:11:31 <FLHerne> andythenorth: Only because you bundle all the industries into one megagrf, no?
11:11:45 <andythenorth> nah, this is just for the chemicals economy
11:11:53 <andythenorth> I have gone overkill on intricate details
11:12:04 <FLHerne> If you didn't do that, it would be less huge, and people wouldn't not know about the non-default ones
11:12:16 <FLHerne> This sounds like it'll be fun :D
11:12:25 <andythenorth> but I'm learning a lot about plastics
11:12:30 <andythenorth> it's really interesting
11:13:02 <andythenorth> I don't think it will be a great subject for a transport game though
11:14:20 <andythenorth> it's all tank cars or pellet hoppers
11:40:26 <DorpsGek_III> [OpenTTD/OpenTTD] giordy commented on issue #8038: Fullscreen mode in MacOSX is almost unusable https://git.io/Jv1n7
11:45:27 <FLHerne> andythenorth: Do power-management warnings not override fullscreen on OSX?
11:45:46 <FLHerne> That seems a bit daft
11:54:22 <andythenorth> FLHerne usually they would, but DOSBox uses a particularly aggressive full-screen mode
11:59:35 <_dp_> this coal mine production is being transported on server but not on clients
12:18:47 <DorpsGek_III> [OpenTTD/nml] matthijskooijman opened issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
12:34:44 *** matt21347 has joined #openttd
12:41:29 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
12:49:50 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
12:57:22 <DorpsGek_III> [OpenTTD/nml] glx22 commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
13:02:07 <Eddi|zuHause> <andythenorth> I have gone overkill on intricate details <-- have you considered turning into factorio modding instead? :p
13:31:59 <blathijs> Hm, it seems that nml 0.5.x broke compatibility somewhere. I tried to compile OpenGFX 0.5.5 with nml 0.5.1, and got an MD5 check mismatch in ogfxe_extra.grf. Is that expected, or a bug?
13:32:51 <blathijs> (I can't easily compare with nml 0.4.5 here, because I'm building in a Debian unstable chroot where 0.4.5 no longer runs)
13:45:25 <FLHerne> blathijs: Mismatch compared to what?
13:45:53 <FLHerne> It's probably expected that the output isn't byte-for-byte identical compared to 0.4.5
13:48:02 <_dp_> not the desync I looking for though
13:50:11 *** Foveafoxy has joined #openttd
13:50:52 *** Foveafoxy is now known as Guest24743
13:54:11 <FLHerne> blathijs: If it's just time.clock, making 0.4.5 run is trivial (`sed -i 's/time\.clock/time\.process_time/' nml/generic.py`)
14:11:15 *** Smedles has joined #openttd
14:25:07 *** Smedles has joined #openttd
14:26:57 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl opened issue #8137: New clients can't join (desync) after funding an industry https://git.io/Jfl8b
14:28:22 <_dp_> still feel that's not the last desync though
14:28:32 <_dp_> but it's the one I was hunting yesterday
14:34:59 <FLHerne> blathijs: That's unlikely to work across nmlc versions, then
14:35:24 <FLHerne> (even minor ones potentially, if they fix a bug that affected the output)
14:35:37 <FLHerne> Although it would be interesting to see what actually changed there
14:37:33 <Samu> something to do with catchment areas
14:37:43 <blathijs> That would mean that an OpenGFX build actually has a hard dependency on the nml version used to compile it (which can be acceptable, but then the nml version should probably be included in the source tarball and I should probably update my OpenGFX Debian packages with such a hard dependency)
14:38:22 <Yexo> I don't think there is a hard requirement that opengfx builds have the same checksum
14:38:33 <Yexo> (apart from the check in the makefile)
14:39:22 <Yexo> OpenTTD indeed uses the checksum to match newgrfs, but that doesn't matter for base sets like opengfx, you can (and should) update those independent of savegames
14:39:40 *** Gustavo6046 has joined #openttd
14:40:59 <DorpsGek_III> [OpenTTD/OpenGFX] matthijskooijman opened issue #41: Should source bundle / tarball be published on github? https://git.io/Jfl4u
14:41:09 <andythenorth> Eddi|zuHause I never clicked with F! :)
14:41:30 <blathijs> Yexo: Doesn't that mean the entire "make check" stuff can be dropped, then?
14:41:42 <Eddi|zuHause> andythenorth: that's alright, me neither :)
14:42:05 <Samu> some of these Peter PR's
14:43:01 *** Smedles has joined #openttd
14:43:21 <Yexo> blathijs: opengfx is so simple that in general there shouldn't be many changes, which is why it worked so far
14:43:34 *** gelignite has joined #openttd
14:43:51 <Yexo> We should first understand what has changed now
14:44:25 <Yexo> See if it's a valid change or not. If valid, we can either update the "make check" stuff or remove it, not sure
14:44:46 <blathijs> That's probably a good idea anyway. I'll just stand by and wait for the experts to figure this out :-)
14:44:47 <Yexo> it is/was a safety check that nml releases don't break stuff
14:45:49 <blathijs> Hm, I thought it was more strict (e.g. like newgrf version), so the Debian package currently fails if the md5sums are different, but that might be too strict, then.
14:48:16 *** Smedles has joined #openttd
14:51:13 <blathijs> (Also, something I realized recently: I *really* like the development community around OpenTTD. It's very much active, diverse and friendly. The infrastructure around automatic building, publishing binaries, etc. is very professional and project structure (commit messages, releases, changelogs, PR policies) is of a very high level. Whatever I, as Debian maintainer, throw in here gets picked up
14:51:15 <blathijs> as another chance to perfect things. All this makes it very much enjoyable to work with all you people, so many thanks for that!)
14:56:54 *** Smedles has joined #openttd
14:57:57 <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick commented on issue #8137: New clients can't join (desync) after funding an industry https://git.io/Jfl8b
14:58:46 <_dp_> Samu, and even know why :p
15:00:48 <glx> missing update on industry creation, but proper rescan on load ?
15:02:16 <Samu> the server is wrong (and all clients that were present when the industry was created)
15:04:01 <_dp_> glx, yeah, doesn't check which tiles are actually producing
15:04:09 <_dp_> and accepting I guess as well
15:08:13 *** Smedles has joined #openttd
15:13:36 *** Smedles has joined #openttd
15:21:42 *** snail_UES_ has joined #openttd
15:25:53 <_dp_> does industry always supply cargo on any tile?
15:26:05 <_dp_> I know acceptance is weird
15:27:09 <_dp_> I can't even find where acceptance tiles are checked
15:27:29 <_dp_> and how it all is supposed to work when stations_near are same for all cargo types
15:29:08 <_dp_> like, I can do a simple fix for desync but this whole thing looks broken %))
15:31:11 <Yexo> Step 1: add check for broken cache in openttd.cpp along with the other desync checks
15:31:27 <Yexo> Step 2: validate it triggers on funding an industry near a station
15:31:36 <Yexo> Step 3: iterate on fix, using new check to validate if it works
15:37:26 <_dp_> Yexo, check is a separate thing, won't help with this desync
15:37:41 <_dp_> and cargo acceptance is just a weird mess, may not even desync at all
15:37:57 <FLHerne> LordAro: "ilayaraja97 and ilayarja97 committed 6 minutes ago"
15:38:04 <FLHerne> How did you manage that? ;p
15:38:35 <FLHerne> (one of them's missing an 'a', too)
15:39:00 <LordAro> i noticed their commit author was broken, it's probably just taken the first 2
15:39:12 <LordAro> i assumed squash would ..squash it all together
15:44:10 <glx> I guess the issue is related to station_near
15:44:12 <FLHerne> blathijs: I built OpenGFX 0.6.0 with nmlc 0.4.5 (lightly patched so it would work) and with 0.5.1, the checksums match in both cases
15:45:27 <blathijs> FLHerne: I haven't tried OpenGFX 0.6.0 yet (had not imported it yet), could be that there is no change there
15:49:48 <FLHerne> How do I build 0.5.5 without GIMP?
15:50:03 <FLHerne> The readme says it's optional, but `make all` fails
15:50:25 <LordAro> comment out the relevant bits of the makefile :p
15:50:42 <blathijs> Dunno, I always build from scratch with Gimp for the .deb
15:50:44 <glx> it's optional but 0.5.5 Makefile is broken I think
15:51:06 <LordAro> alternatively, `find -name '*.png' -exec touch {} \;` might quieten it
15:51:24 <LordAro> or whatever format the images are in
15:51:29 <glx> and IIRC different gimp version can generate different PNG
15:51:35 <FLHerne> "This doesn't break the build process, but causes all PNG files to be regenerated and that causes all of them to diff from the repo."
15:51:45 <FLHerne> ^ from a GitHub issue
15:51:58 <FLHerne> Possibly that's the issue
15:52:23 <FLHerne> Sprites aren't included in the grf md5
15:53:38 <blathijs> The .deb build always regenerates using gimp, and I haven't seen an MD5-sum-failure because of that so far.
15:54:29 <blathijs> (It *could* be that the build failure I'm seeing now is really due to a different gimp version, rather than an nml version, but I have no way of telling currently)
15:56:55 <FLHerne> grfid doesn't consider the pixel data (to allow for optional 32bpp/extra-zoom versions), so I don't think that should be able to matter
16:00:33 *** matt21347 has joined #openttd
16:04:43 <FLHerne> blathijs: Ok, I also get a mismatch with 0.5.5/0.5.1, without doing a GIMP rebuild
16:05:08 *** supermop_Home_ has joined #openttd
16:14:06 <FLHerne> And it matches with 0.4.5
16:16:38 <Samu> FindStationsAroundTiles hmm...
16:17:02 <Samu> it has given a 3x3 rectangle of that coal mine
16:17:38 <Samu> it should give only the tiles pertaining to the industry, only some of the tiles in that 3x3 belong to it
16:19:50 <Samu> line 1701 industry_cmd.cpp, the ind->location should maybe be sliced into multiple 1x1 checks while iterating ind->location
16:19:55 <LordAro> something to do with the optimisations implemented?
16:21:17 <blathijs> FLHerne: None of those numbers mean anything to me, so I can't really comment :-)
16:23:59 <glx> Samu, _dp_: I'd blame #7235
16:24:29 <DorpsGek_III> [OpenTTD/OpenTTD] ilayaraja97 commented on issue #8131: Missing bounding boxes for bridge pillars of height 1 cause graphical glitches https://git.io/JfWqh
16:24:29 <Yexo> FLHerne: Thanks. That change is safe
16:24:48 <Yexo> It changes the offset for tram track sprites from unset (defaults to 0) to explicitly set to 0
16:25:26 <Yexo> Slight deoptimization in file size
16:25:38 <Yexo> One could argue that's a bug in nmlc, but it won't affect visible behavior
16:27:36 <Yexo> hmm, but openttd expects 119 sprites since 1.10, while apparently ogfxe_extra is still only providing 113
16:28:11 <Samu> using this->industry->location isn't totally correct
16:28:29 <glx> Yexo: hmm that's changed in nml 0.5.0 only IIRC
16:28:58 <FLHerne> Yexo: This is an old OGFX version, so that's fine
16:29:05 <Samu> need to look at FIRS fishing grounds
16:30:11 <FLHerne> What's the purpose of the `8n` rather than `0n` types in Action5?
16:30:34 <FLHerne> The doc says "If bit 7 is set, the offset variable needs to be set. Bit 7 may only be set if the type supports it."
16:30:48 <Yexo> nmlc explicitly sets the offset to 0 if the number of sprites is different than the maximum
16:30:53 <Samu> but let me verify for sure
16:31:24 <FLHerne> But not why I'd want to set bit 7
16:31:32 <FLHerne> Oh, because without it the offset is ignored
16:31:39 <FLHerne> But we don't need to set it anyway
16:32:00 <Yexo> FLHerne: docs are correct, but not worded very well: "1. Do not set bit 7 if the type doesn't support it. 2. Meaning of bit 7: a sprite offset follows"
16:32:51 <FLHerne> Yexo: Where's that from?
16:33:25 <Yexo> I was trying to reword it in a clearer way
16:34:33 <Yexo> Remove the "or num_sprites != num_required" in nml/actions/action5.py line 119 to remove the diff
16:37:28 <Yexo> There we go: I added that myself apparently. Luckily I also documented the reason back then: nforenum gives a warning if the explicit offset of zero is not present
16:39:18 <Samu> Industry TileArea needs to be converted to BitmapTileArea
16:39:25 <Samu> i just don't know how to
16:39:33 <FLHerne> Yexo: Ok, makes sense
16:40:03 <FLHerne> I don't think lack of byte-for-byte identical output across major versions is a bug anyway
16:41:18 <FLHerne> blathijs will just have to patch their build script, or use OGFX 0.6.0
16:41:25 <glx> I guess nforenum will expect 113 sprites for this action 5 type
16:42:43 <planetmaker> should be ok to require a matching OpenGFX version, no?
16:43:38 <FLHerne> Well, assuming Debian has current OTTD it'll be needed anyway
16:44:01 <FLHerne> (else missing sprite warnings)
16:46:27 <blathijs> I'll probably do both, update to OGFX 0.6.0 and in that update, remove the `make check` from the build (or maybe do another upload of 0.5.5 just to remove make check maybe)
16:47:42 <_dp_> glx, well, yeah, but what to do with it now is the question
16:47:48 <_dp_> I guess Yexo's plan is ok
16:47:58 <blathijs> If everything is new (or at least the same version the original OGFX was built with), then things will work out, but it is generally a good idea if you can also mix and match versions (and if you cannot, then version requirements should preferably be explicit, which is a bit tricky in this case)
16:48:04 <_dp_> fix desync, add check, release 1.10.2 and wait for new desyncs xD
16:49:12 <glx> I'd add the check before the fix :)
16:49:35 <glx> so it's easy to see the check works :)
16:49:56 <_dp_> glx, well, sure, do it :p
16:50:07 *** supermop_Home_ has quit IRC
16:50:19 <_dp_> I've no idea what it checks anyway
16:50:25 <glx> we're ok it's related to near_station ?
16:50:53 <_dp_> glx, yeah, I'll do a simple patch for that desync
16:51:25 <Yexo> Isn't Station::industries_near also wrong?
16:52:05 <Samu> i found where the error is
16:52:54 <_dp_> it's a separate issue but I feel like DC_EXEC check is mising there
16:53:36 <glx> the highlightedf function is called in AfertLoad()
16:54:13 <_dp_> Samu, I found it 5 hours ago :p
16:54:44 <_dp_> it's not a problem to add tile check there, I'll do that right now
16:55:02 <_dp_> problem is that whole *_near stuff doesn't look right
16:55:52 <Samu> stations_near is empty at the moment
16:56:04 <glx> I think the cache check should store all industry station_near (maybe towns too), then recompute all, and compare
16:58:14 <Samu> just tested it, and the station no longer gets coal
17:00:51 <Samu> it's probably the wrong approach
17:09:10 <DorpsGek_III> [OpenTTD/OpenTTD] telk5093 opened issue #8138: Hotkeys don't work in non-english IME (such as Korean) https://git.io/Jflgb
17:23:34 <Samu> _dp_ CmdRemoveFromRailStation is only called in DC_EXEC mode from what I gather
17:30:05 <_dp_> Samu, can't AI call it without?
17:30:14 *** Wormnest has joined #openttd
17:34:12 <_dp_> Samu, and actually even player can, just press shift while removing station
17:34:26 <Samu> sorry, I am wrong. What I meant to say was st->RecomputeCatchment(); isn't called in DC_EXEC mode
17:37:26 <_dp_> whatever, I already understood it myself
17:37:36 <_dp_> there are no affected_stations without DC_EXEC
17:38:11 <glx> ok let's test the cache check I just added
17:38:18 <_dp_> would still add an explicit check just to foolproof it though
17:55:11 *** Progman has joined #openttd
17:58:25 <Samu> DC_TEST doesn't exist either
18:05:32 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #8137: New clients can't join (desync) after funding an industry https://git.io/Jfl8b
18:05:38 <Samu> that feeling when I'm trying to help
18:07:43 <glx> ok my cache checks detects the mismatch
18:11:42 *** frosch123 has joined #openttd
18:14:05 <_dp_> lol, somehow while fixing desync I ended up with a PR that a) doesn't fix desync, b) is not needed to fix desync
18:14:12 <_dp_> probably fixes something else though xD
18:15:09 <_dp_> well, I did'n actually pr it yet
18:15:16 <_dp_> I'll just stash it for now I guess
18:15:48 <LordAro> _dp_: we're holding 1.10.2 for this, so any further fixes are welcome :p
18:16:20 <Yexo> _dp_: For desyncs such as this, the much bigger problem is finding the root cause. You've done a great job at that
18:17:19 <Samu> JGR fixes the issue in a more professional way
18:20:16 <_dp_> LordAro, well, if anyone is finding newgrf house var 64 doing weird stuff I migth know why
18:20:23 <_dp_> no idea what it's supposed to do though
18:21:28 <glx> JGR must have a modified CheckCaches()
18:24:21 <Yexo> I can also trigger his checks without causing a desync based on some town caches
18:25:43 *** tokai|noir has joined #openttd
18:25:43 *** ChanServ sets mode: +v tokai|noir
18:44:13 <DorpsGek_III> [OpenTTD/OpenTTD] Andrew350 commented on issue #8131: Missing bounding boxes for bridge pillars of height 1 cause graphical glitches https://git.io/JfWqh
18:48:02 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 opened pull request #8139: Add: stations_near and industries_near cache check https://git.io/JflrE
18:50:52 *** luaduck has joined #openttd
19:09:51 *** Dave is now known as Guest24774
19:11:34 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl opened pull request #8140: Fix #8137: New clients can't join (desync) after funding an industry https://git.io/JfloZ
19:12:36 <Guest24774> Trying to get world map that was on naver website? does anyone have it?
19:16:18 <Samu> I think JGR does it better
19:21:14 <Samu> what is st->AddIndustryToDeliver(ind)
19:22:40 <glx> yes JGR FindStationsAroundTiles() is better, but I like your AddIndustryToDeliver() use in PopulateStationNearby()
19:23:59 <Samu> but that's not how it works :(
19:24:41 <_dp_> FindStationsAroundTiles is a mess that doesn't even work for arbitrary tile areas
19:25:13 <_dp_> it's only saving grace is that it's only being called for a very specific areas
19:25:53 <_dp_> except mb for that newgrf thing that I've no idea how is supposed to work
19:27:20 <_dp_> If anything it may be better to just call RecomputeCatchment directly from PopulateStationsNearby
19:27:53 <_dp_> not as effecient but funding doesn't happen often and that leaves less opportunities for errors
19:32:41 <Samu> I wonder how is AddIndustryToDeliver used, cus the station still doesn't accept coal
19:32:50 <Samu> testing with a PowerStation
19:34:44 <glx> AddIndustryToDeliver() does just what the the "/* Test if industry can accept cargo */" block did
19:36:35 <Samu> power station was added, but station still does not accept coal
19:37:00 <Samu> because the industry tile it reaches doesn't accept coal
19:37:16 <_dp_> yeah, acceptance is weird in openttd, but that's another story
19:37:30 <glx> that's ok, you must cover the accepting tiles
19:37:59 <Dave_> Good evening everyone where can i get the naver world map for openttd?
19:38:00 <glx> same when you place your station near a refinery
19:38:36 <_dp_> glx, it's known behaviour but weird implementation
19:38:42 <_dp_> I also suspect some bugs
19:39:32 <Yexo> Dave_: I believe if anyone had known which map you mean you would've gotten an answer
19:39:45 <Yexo> Have you tried the in-game online content system already?
19:40:55 <Dave_> the world map with real city locations and names.
19:43:41 <FLHerne> Dave_: There's more than one of those ;-)
19:45:37 <Dave_> tried it not the one i am looking for thanks
19:45:47 <DorpsGek_III> - Update: Translations from eints (by translators)
19:47:16 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #8139: Add: stations_near and industries_near cache check https://git.io/JflKV
19:48:11 <JGR_> I can turn that into a PR if useful?
19:48:22 <JGR_> In general I've got loads of desync-related stuff in my branch
19:48:44 <glx> I'll adapt it myself, lots of code changed in this area anyway
19:49:43 <JGR_> It's probably be simpler to copy from a more recent version, the loop changes have been done already
19:51:36 <LordAro> JGR_: i'm sure any desync stuff would be appreciated :)
19:55:36 <JGR_> I've been getting desync bug reports from users for a while now
19:56:11 <JGR_> Reproducing them from user feedback tends to be difficult, so I've tried to automate things a bit
19:56:27 <glx> indeed you check a lot more than us, that clearly could help
19:57:59 <JGR_> In my branch, when a desync does occur, CheckCaches is run on the client and server, any output from these is added to a log resembling a crashlog
19:58:15 <JGR_> The client and server exchange logs and these are written to files, and into savegames
19:59:46 <JGR_> As well as using the random seed to detect desyncs, I'm also hashing key bits of game state into a different seed which is compared between client and server
20:00:51 *** mcbanhas has joined #openttd
20:01:03 <_dp_> JGR_, but can't server already be ahead when it receives desync report from the client?
20:01:32 <JGR_> Yes, so the savegames would not be identical
20:01:53 <_dp_> that doesn't seem to be very helpful then :(
20:02:35 <_dp_> 1 tick of simulation is already enough to mess up the whole map
20:02:37 <JGR_> However running CheckCaches immediately often finds the problem, and interpreting the output of that requires a savegame
20:10:27 <LordAro> JGR_: if you can add some stuff in the debugging_desyncs.md doc at the same time, would be much appreciated
20:15:17 *** supermop_Home has joined #openttd
20:16:14 <supermop_Home> two neat new grfs bringing me join
20:18:50 <supermop_Home> man my brain is broken
20:20:06 <JGR_> Does all of the stuff I outlined sound reasonable, or just a subset? I'm sure there's a line somewhere of changes which are too invasive.
20:20:53 <supermop_Home> Opengfx+ stations, and town layout
20:24:44 <LordAro> JGR_: seems reasonable to me
20:25:38 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison opened pull request #8141: Fix #8137: Rectangular industry area used for stations_near calculation https://git.io/Jfliv
20:30:29 <_dp_> great, so now we have competing prs :p
20:30:32 <FLHerne> frosch123: Is SpriteCache used just for caching files between nmlc runs, or also to deduplicate sprites or to avoid re-processing them during a single run?
20:31:03 <FLHerne> (i.e. if I stopped using it altogether when --no-cache is passed, would that break stuff?)
20:31:33 <_dp_> imo if change FindStationsAroundTiles it should be made into template and use_nearby moved to StationFinder
20:33:33 *** plastic has joined #openttd
20:33:48 <JGR_> _dp_: Happy for you to take precedence on this
20:34:46 <JGR_> Mine can be closed if something else is merged
20:40:39 *** plastic has joined #openttd
20:41:37 <_dp_> it's just funny that of all the bugs to work on this stupid thing that no one cared about for year suddenly gets 3 patches in one day xD
20:42:31 <frosch123> FLHerne: 1 and 2, not 3
20:44:53 <frosch123> FLHerne: disabling it probably means to keep all sprites in memory, so in case of 32bpp grfs some 100 mb more address space
20:48:52 <mcbanhas> Hi guys, would anyone be kind enough to give me a hand with git? I'm ready to submit my first batch of string changes, and first and foremost I'm not sure whether I should create a new PR or edit the old one.
20:49:03 <frosch123> FLHerne: actually, it also somewhat does 3. there was a big performance gain by opening huge source images only once, instead of repeatedly for every single sprite in them
20:50:20 <frosch123> FLHerne: why do you not want to use the cache? i mean you can just delete it, if you do not want it
20:50:35 <frosch123> wasn't there an option to hard-reset it?
20:51:46 <frosch123> lol, "nml --help" says that disabling the cache may speed up :p
20:52:08 <frosch123> i think you have to hand-craft that scenario
20:57:18 <Samu> how does this checkcache starts? is there a command?
20:59:33 <Yexo> It's executed when debug_level_desync >= 1
21:00:57 <Samu> i typed 9 and this is writting savegames somewhere
21:01:22 <Yexo> >=1, so 2 is fine, as is 1
21:01:44 <LordAro> Samu: i think you know that 2 >= 1 by now
21:02:53 *** Gustavo6046 is now known as Guest24787
21:02:57 *** Gustavo6046 has joined #openttd
21:06:55 <Samu> that's why i wasn't seeing anything
21:14:34 <glx> and it won't print on the console, it's only in commands-out.log
21:15:10 *** frosch123 has joined #openttd
21:16:37 <glx> <@Yexo> It's executed when debug_level_desync >= 1 <-- it's skip for <=1, so 2 is the minimim :)
21:17:06 <Yexo> Thanks for the correction :)
21:23:52 <FLHerne> frosch123: There's a bug where it creates the cache directory even if --no-cache is set
21:24:20 <FLHerne> The most straightforward fix would just be to not create the cache if it wasn't really being used
21:24:53 <FLHerne> But since it is, I'll do something else
21:25:12 <Samu> glx, it corrects the cache, is it supposed to do that?
21:25:39 <FLHerne> And yes, I saw that description, and couldn't figure out if it's supposed to say "disable (the cache, which might be faster)" or "(disable the cache), which might be faster" :P
21:25:55 <glx> yes as all cache checks it fixes the cache while checking
21:26:06 <frosch123> FLHerne: it's probably an ancient message
21:27:00 <glx> but it still reports the error it any
21:27:04 <frosch123> nml < 0.4 only dumped sprites into the cache. only with >= 0.4 there were significant gains with processing sprites out of order
21:28:08 <Samu> makes it harder to get clients desync this way
22:16:30 <glx> Samu: cache check is there to detect possible desyncs, and it also prevents them, but it's cpu intensive, so only enabled when hunting for desync cause
22:42:58 <LordAro> glx: so what are we doing about the cache check?
22:44:48 <LordAro> other than also checking catchment_tiles, i don't really see how JGR's solution is "cleaner"
22:45:18 <glx> mine is using a map, vector is better
22:49:54 <andythenorth> ha ha, I am going to hate drawing cargo icons for all these chemicals
22:50:11 <andythenorth> methanol, ethylene, propene etc
22:50:20 <LordAro> glx: well, feel free to rewrite yours to use vectors, i guess
22:50:29 <andythenorth> maybe I can fit the chemical symbol in an icon :P
22:50:32 <LordAro> due to the FOR_ALL removal, it'd have to be basically rewritten anyway
22:51:27 <glx> LordAro: yeah I'll switch to vectors (watching twitch for now)
22:51:59 <LordAro> glx: any particular thoughts about the solution?
22:52:09 <LordAro> either of the solutions*
22:53:35 <glx> I'd say a mix of both, I prefer JGR solution, but I like the AddIndustryToDeliver() usage
22:54:27 <LordAro> tbh i'd suggest that FindStationsAroundTiles should be an Industry member function
22:54:52 <glx> it's used for towns too I think
22:56:15 <glx> but it should maybe merge into StationFinder
22:56:22 <DorpsGek_III> [OpenTTD/nml] jrook1445 opened issue #140: 0.5.1 - animated forest tiles from OpenGFX+ Industries disappear https://git.io/JflSO
22:56:48 <_dp_> use_nearby should go to stationfinder as it doesn't work without anywaya
22:57:31 <_dp_> and mb separate finder for houses
22:58:00 <_dp_> use_nearby for industry can be dropped completely, it's not used anyway
22:58:23 <LordAro> mm, there's a certain amount of "trying to be too generic" going on
22:58:46 <glx> templated StationFinder() maybe
22:59:13 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on issue #140: 0.5.1 - animated forest tiles from OpenGFX+ Industries disappear https://git.io/JflSO
22:59:21 <LordAro> unlikely to be worth it, i'd think?
22:59:50 <_dp_> finder is already an iterator so no point templating
23:00:00 <_dp_> FindStationsAroundTiles can be templated though
23:00:14 <_dp_> in my pr I already kinda prepared for templated FindStationsAroundTiles
23:00:34 <LordAro> _dp_: perhaps you should finish it :)
23:01:02 <_dp_> I already have most of it stashed anyway :)
23:01:12 <_dp_> should it be same pr though?
23:01:17 <_dp_> has nothing to do with desyncn
23:03:00 <glx> anyway I'm not fan of copy/pasting FindStationsAroundTile() inside PopulateStationsNearby()
23:04:23 <LordAro> _dp_: possibly not, but if it's part of the same work, there's no good arbitrarily separating it
23:05:34 <glx> I'm not against a multi commit PR with first rewrite to ease fixing, then the fix itself
23:05:39 <_dp_> it depends on one another, I either copy FindStationsAroundTile or template it
23:06:40 <_dp_> multicommit prs are a pain to change if needed
23:07:07 <_dp_> or at least I've no idea how xD
23:07:42 <LordAro> git commit -m "tmp" && git rebase -i with fixup into the original commit
23:07:49 <LordAro> fix any conflicts if necessary
23:07:54 <LordAro> that's how i do it, anyway
23:08:14 <michi_cc> Though sacrilegious for some, a GUI tool can help tremendously with that :)
23:08:46 <glx> and to split a commit you put it twice in the rebase with "edit" on the first one
23:12:40 *** ChanServ sets mode: +v tokai
23:25:25 <mcbanhas> >me is trying the vactrain newgrf for the first time
23:25:34 <mcbanhas> oh god this is amazing
23:31:49 <FLHerne> Trains, but really fast ?
23:39:27 <FLHerne> Vacuuuuuum tubes, no less
23:40:40 <mcbanhas> it's sad, because we wont be seeing stuff like that IRL during our lifetimes
23:41:02 <mcbanhas> Even most maglev projects sound like pie in the sky at the moment.
23:42:14 *** Wormnest has joined #openttd
23:44:20 <_dp_> now every stupid thing wants to go to h file :(
23:49:15 <_dp_> what's next junk h name after _map.h and _func.h ?
23:52:01 <nielsm> there's _type.h but that's mostly basic typedefs and enums
23:52:06 <_dp_> it should rly got to _func but _map depends on _func and I can't untangle that mess :(
23:52:27 <nielsm> otherwise invent a new one
23:52:58 <nielsm> if you can avoid including a large chunk of code everywhere that will help compilation times a bit
23:55:15 <glx> we use .hpp for templated drivers
23:57:43 <glx> hmm no they don't use templates
continue to next day ⏵
