Times are UTC Toggle Colours
00:11:15 <supermop_Home_> somehow i never have the DVTs in iron horse 00:20:52 <DorpsGek_III> [OpenTTD/OpenTTD] CottonTheButton opened issue #8158: Game crashes on startup https://git.io/JfEsP 00:27:26 <DorpsGek_III> [OpenTTD/OpenTTD] James103 commented on issue #8158: Game crashes on startup https://git.io/JfEsP 00:34:54 *** Wormnest has joined #openttd 00:39:59 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8158: Game crashes on startup https://git.io/JfEsP 00:39:59 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 closed issue #8158: Game crashes on startup https://git.io/JfEsP 01:56:11 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfEnv 02:09:28 *** Wormnest has quit IRC 02:22:58 *** Gustavo6046 has quit IRC 02:35:21 *** Flygon has joined #openttd 02:35:52 *** Gustavo6046 has joined #openttd 02:54:30 *** Yexo is now known as Guest25402 02:54:36 *** Yexo has joined #openttd 02:54:36 *** ChanServ sets mode: +o Yexo 03:00:40 *** D-HUND has joined #openttd 03:01:51 *** Guest25402 has quit IRC 03:04:06 *** debdog has quit IRC 03:11:50 *** glx has quit IRC 05:05:32 *** Yexo has quit IRC 05:40:56 <DorpsGek_III> [OpenTTD/nml] Andrew350 opened issue #147: Metric speed values are still slightly off https://git.io/JfEBi 05:46:29 *** kamnet has quit IRC 06:03:50 *** sla_ro|master has joined #openttd 06:15:21 *** snail_UES_ has quit IRC 06:19:49 *** andythenorth has joined #openttd 06:21:45 <DorpsGek_III> [OpenTTD/OpenTTD] fsimonis commented on pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/JfE0c 07:25:47 <DorpsGek_III> [OpenTTD/nml] Eddi-z commented on issue #147: Metric speed values are still slightly off https://git.io/JfEBi 07:48:51 *** cHawk- has quit IRC 07:51:04 *** Eddi|zuHause has quit IRC 07:51:51 *** Eddi|zuHause has joined #openttd 08:00:20 *** iSoSyS has joined #openttd 08:04:10 *** matt21347 has joined #openttd 08:05:10 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8156: Fix #8155: Roadtype speed limit in toolbar dropdown in scenario editor was doubled. https://git.io/JfE2o 08:05:43 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #8151: Fix: Desync after house replacement https://git.io/JfRPm 08:06:19 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro dismissed a review for pull request #8135: Prepare for 1.10.2 release https://git.io/JfWH4 08:14:30 *** iSoSyS has quit IRC 08:29:13 <_dp_> is there any convenient way to advance the save for 1 tick? 08:29:56 <Eddi|zuHause> sending unpause/pause from the console? 08:30:52 <LordAro> _dp_: some minor modifications to the debug desync code might do well enough 08:31:00 <LordAro> desync debug* 08:32:00 <Eddi|zuHause> slightly more elaborate or future proof would be to make ctrl+click on the pause button advance in single steps or something 08:32:18 <_dp_> just console command will be enough 08:32:44 <_dp_> though atm I don't even see a way to pause on load 08:32:47 <Eddi|zuHause> adding a console command is pretty easy 08:33:12 <Eddi|zuHause> pause on load you can hack into afterload 08:34:37 <Eddi|zuHause> but that would also be a candidate for an actual feature 08:36:28 <Eddi|zuHause> (or just make the savegame while paused) 08:44:38 *** gelignite has joined #openttd 08:47:34 *** cHawk- has joined #openttd 08:52:01 *** Samu has joined #openttd 08:58:00 <DorpsGek_III> [OpenTTD/nml] matthijskooijman commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq 08:58:34 *** andythenorth has left #openttd 08:59:50 <Samu> hi 09:14:30 *** cHawk- has quit IRC 09:19:45 *** cHawk has joined #openttd 09:22:51 <_dp_> ok, looks like it's already somewhat late to save when server receives the desync 09:23:09 <_dp_> server was 80 ticks ahead so even after advancing the game diff is still massive :( 09:23:31 <_dp_> I may have found the desync anyway 09:23:37 <_dp_> *but 09:26:26 *** supermop_Home_ has quit IRC 09:48:33 *** tokai has joined #openttd 09:48:33 *** ChanServ sets mode: +v tokai 09:53:45 *** arikover has joined #openttd 09:55:23 *** tokai|noir has quit IRC 09:56:02 <Samu> new desyncs? 09:56:10 <Samu> you're becoming an expert! 09:56:22 <_dp_> rofl 11:26:41 <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #21: Eddi-nml branch for ActionC support https://git.io/fhpED 11:30:10 <Eddi|zuHause> that was probably both overdue and pointless... 11:42:39 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro updated pull request #8135: Prepare for 1.10.2 release https://git.io/JfW9f 11:55:46 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #70: Reduce boilerplate for creating BinOps https://git.io/Jey9d 12:00:44 <Eddi|zuHause> so in nml "make regression", can i select a single test to run instead of all of them? 12:02:40 <_dp_> LordAro, in case you want to release 1.10.2 smth needs to be done with Town::accepted_cargo and subsides imo 12:03:36 <Eddi|zuHause> _dp_: why do you think it's that urgent? 12:03:51 <_dp_> Eddi|zuHause, because it desyncs 12:03:59 <_dp_> savegame stuff is irrelevant there 12:04:13 <LordAro> _dp_: you're not wrong 12:04:24 <LordAro> i was just making sure i had all the backported stuff in the PR 12:04:34 <LordAro> though we do need to do a release sooner rather than later 12:04:53 <LordAro> fewer bugs in a new release is better than all the bugs in an old release 12:05:03 *** ZirconiumX has quit IRC 12:05:22 <_dp_> it should be a relatively easy fix if we're ok breaking subsidies a bit :) 12:05:58 <_dp_> or should I say in a different way xD 12:06:23 *** ZirconiumX has joined #openttd 12:06:58 <_dp_> it's amazing how that all works actually 12:07:05 <FLHerne> Eddi|zuHause: `make -C regression 001_action8` 12:07:23 <FLHerne> (or cd regression; make 001_action8` 12:07:29 <FLHerne> ) 12:07:39 <_dp_> it maintains acceptance matrix updating it on every relevant operation (except where bugged) 12:07:47 <Eddi|zuHause> FLHerne: alright, seems to work 12:08:19 <_dp_> recalculates those matrices for each town each month in a very ineffecient way (scanning every tile 9 times doing cb calls) 12:08:26 <FLHerne> Eddi|zuHause: Why is it useful? Even on my painfully-slow laptop the tests only take 30s or so 12:08:43 <_dp_> and then subside just have 1/16 chance to use those matrices for 2 towns each month xD 12:09:05 <Eddi|zuHause> FLHerne: i added some debug output and want to reduce the scope 12:09:05 <LordAro> _dp_: i'm not sure that's something that can be backported 12:09:15 <FLHerne> ok 12:09:25 <LordAro> not that i disagree that the current implementation is silly 12:09:26 <_dp_> LordAro, it can be backported just fine as long as it stays in a savegame 12:09:49 <_dp_> but will be just unused 12:09:54 <FLHerne> Eddi|zuHause: I think your patch is a bit silly, btw :p 12:10:13 <Eddi|zuHause> the ActionC? 12:10:18 *** supermop_Home_ has joined #openttd 12:10:29 <Eddi|zuHause> well, it's an essential part of compiling CETS 12:10:55 <Eddi|zuHause> but nobody else seems to be able to think of a use for it... 12:11:35 <FLHerne> NML already has comments, adding a weird 'comment()' block that only makes sense for your specific usecase seems wrong 12:12:42 <FLHerne> And having to patch NML's output together after the fact is a bug that should be fixed, not a usecase to encourage :-/ 12:13:23 *** gelignite has quit IRC 12:13:55 <Eddi|zuHause> well... someone once thought that including action C in NFO was a good idea 12:13:57 <_dp_> LordAro, I kind of started on pr already btw, was just mostly reading code till now 12:14:05 <_dp_> but transitioning to writing it atm :) 12:15:23 <FLHerne> Eddi|zuHause: Where does CETS live now? Devzone doesn't show any commits for a while 12:15:47 <Eddi|zuHause> depends on what you call "live" :p 12:16:21 <FLHerne> Well, where do I get a current version of the source, so I can crash my laptop with it? 12:16:41 <Eddi|zuHause> there should be all commits on devzone 12:16:49 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfEMp 12:19:58 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfEDL 12:33:31 *** glx has joined #openttd 12:33:31 *** ChanServ sets mode: +v glx 12:37:51 <Eddi|zuHause> there was supposed to be a small change to the source to turn it back into single-file mode, but i can't find it 12:38:50 <FLHerne> Eddi|zuHause: Yeah, I was trying to figure out how to do that 12:39:34 <Eddi|zuHause> i was hoping to find it in r734 12:39:47 <Eddi|zuHause> but it's not as obvious as i would have hoped 12:49:28 <FLHerne> Eddi|zuHause: Can I just revert 734 altogether? 12:49:44 <Eddi|zuHause> i don't think that'll work 12:50:43 <Eddi|zuHause> in scripts/files.py there's vehicle_file, which is probably the right place 12:53:55 <FLHerne> [13:52][9757][flh ~/projects/cets/]$ hg checkout default (hg)-[default|merging]- 12:53:56 <FLHerne> abort: outstanding merge conflicts 12:54:02 <FLHerne> [13:53][9758][flh ~/projects/cets/]$ hg merge --abort (hg)-[default|merging]- 12:54:04 <FLHerne> abort: no merge in progress 12:54:17 <FLHerne> And they say git is awkward and counterintuitive 12:56:41 <Eddi|zuHause> i've no clue how you handle conflicts from command line 12:58:04 *** WormnestAndroid has quit IRC 12:58:05 *** WormnestAndroid has joined #openttd 12:59:41 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfES2 13:01:38 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 updated pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbqc 13:04:36 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/JfES1 13:07:34 <Eddi|zuHause> FLHerne: as far as i can recover, relevant revisions are r730 through r736 and r839 13:08:31 *** cHawk has quit IRC 13:08:31 <Eddi|zuHause> but i don't know if anything else depends on those 13:12:42 <Eddi|zuHause> i still doubt that reverting them will do any good 13:14:55 <FLHerne> Yeah, I still get conflicts 13:15:08 <FLHerne> Some of which are non-obvious how to revert 13:17:08 <FLHerne> tbh, reverse-engineering CETS' build system just to replicate an nml bug is more work than I feel like doing just now :-/ 13:17:32 <Eddi|zuHause> FLHerne: let me stirr around for a bit, and i get back to you 13:18:03 <FLHerne> Thanks 13:18:05 <Eddi|zuHause> FLHerne: but from what i remember, it was yacc blowing up because of python's string handling 13:18:16 <Eddi|zuHause> not sure how much nml can do there 13:18:59 <FLHerne> I've made a couple of attempts at implementing bits of the parser in C 13:19:11 <FLHerne> They didn't work terribly well, though 13:22:07 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 updated pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbqc 13:31:39 <_dp_> what's the canonical way to write constants to a savegame? 13:32:19 <_dp_> SLEG_VAR? 13:37:03 <Eddi|zuHause> i'm getting a weird "unexpected token" error from nmlc that i'm not sure where it's coming from 13:37:39 <Eddi|zuHause> _dp_: why would you need constants in a savegame, if they're constant? 13:37:58 <_dp_> Eddi|zuHause, to avoid bumping the savegame version 13:38:20 <Eddi|zuHause> i'm not following... 13:38:53 <_dp_> Eddi|zuHause, nvm, I though of a way already 13:39:00 <LordAro> _dp_: if we need to bump the savegame, we will 13:39:09 <LordAro> it just makes things complicated if we do it in a release branch 13:39:18 <_dp_> nah, it's just a code style problem 13:39:23 *** snail_UES_ has joined #openttd 13:41:21 *** arikover has quit IRC 13:44:57 <glx> <Eddi|zuHause> i'm getting a weird "unexpected token" error from nmlc that i'm not sure where it's coming from <-- maybe show the code and the error message 13:47:57 <DorpsGek_III> [OpenTTD/nml] glx22 commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq 13:48:59 <Eddi|zuHause> glx: probably comes from my rebase earlier 13:51:24 <FLHerne> Eddi|zuHause: p_error in parser.py 13:51:51 <FLHerne> It means the parser reached a token that doesn't make sense in its current state 13:52:12 <FLHerne> i.e. your nml code has a syntax error, or the parser's broken 13:52:52 <FLHerne> It should tell you what the unexpected token is, and where 13:53:04 <Eddi|zuHause> yay, paste.openttdcoop.org -> " Your IP address is listed as a malicious IP. " 13:53:21 <glx> paste is long time broken 13:53:39 <Eddi|zuHause> that's the first time i hear of that 13:54:01 <glx> it's like that for months 13:57:13 <Eddi|zuHause> FLHerne: so, try https://pastebin.com/eBrKq6us ... it'll still try to go nml->nfo->grf (which might fail), but now everything is in one single nml run 13:57:34 <Eddi|zuHause> and i disabled all the "comment" stuff so should work with stock nml 13:58:23 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq 14:01:50 <Eddi|zuHause> FLHerne: also, src/table/CETS_tracking_table.tsv might need restoring to pre-r724 for maximum effect 14:02:29 <Eddi|zuHause> (not sure if it's that easy) 14:07:37 *** gelignite has joined #openttd 14:11:39 <Eddi|zuHause> FLHerne: the file you'll be looking at would be src/cets.onml 14:18:54 <FLHerne> Eddi|zuHause: Thanks, that's working 14:21:17 <supermop_Home_> hi all, I've not yet used the gh for anything.... if i want to propose/ suggest / submit an improved sprite for opengfx - do i do that there as an issue? 14:21:48 <LordAro> supermop_Home_: a PR would be preferred, but an issue would work as well 14:22:10 <FLHerne> Eddi|zuHause: Interesting that the file isn't any *bigger* than the FIRS/Horse ones, which take a long-ish but somewhat reasonable time 14:22:56 <supermop_Home_> ok. i thought a pr was specifically for submitting some code 14:23:14 <LordAro> everything is code 14:23:26 <LordAro> as far as the repo is concerned 14:23:27 <Eddi|zuHause> supermop_Home_: a PR is specifically for changing any file 14:23:43 <Eddi|zuHause> code, sprite, docs, doesn't matter 14:24:11 <supermop_Home_> i mean i guess a png is just a bunch of bits... would i submit a new sprite sheet with my sprite on it, or just my sprite? 14:24:30 <LordAro> supermop_Home_: imagine you're making a change to one of your own GRFs 14:24:54 <Eddi|zuHause> supermop_Home_: the whole file would probably be easier 14:25:13 <supermop_Home_> LordAro I've never really touched a base set before so idk if a file for just that one item (station roof) would be desirable 14:25:29 <LordAro> OGFX isn't exactly consistent 14:26:33 <Eddi|zuHause> FLHerne: i beleve r724 was specifically for reducing the file size to something that can be managed 14:27:00 <glx> hmm adding stations to nml seems complicated, they have stuff in action 0 when other features use action 2 14:27:01 <FLHerne> Eddi|zuHause: This is with your patch 14:27:30 <FLHerne> cets.onml is 11MB, which is the same as FIRS 14:27:33 <LordAro> glx: that's basically what made Yexo quit last time :p 14:27:35 <LordAro> iirc 14:27:37 <FLHerne> But it takes about 8x longer to parse 14:27:48 <LordAro> (also the new job, and life etc) 14:28:49 <Eddi|zuHause> FLHerne: yes, and reverting r724 would add some 200 vehicles on top 14:29:10 <FLHerne> Ok 14:29:44 <Eddi|zuHause> i'm currently trying to see how easy it would be to reinstate those to the table, there might have been some new columns in the meantime 14:30:10 <FLHerne> But my point is that it's not purely the filesize that's the issue 14:30:28 <FLHerne> nmlc is alright with 11MB source files, just not *this* 11MB source file 14:31:04 <FLHerne> (I haven't the faintest idea why yet) 14:31:17 <Eddi|zuHause> hehe :) 14:33:52 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl opened pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfE5M 14:36:47 <DorpsGek_III> [OpenTTD/nml] glx22 commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq 14:37:51 *** Wormnest has joined #openttd 14:40:26 <DorpsGek_III> [OpenTTD/nml] FLHerne closed pull request #143: Add: Script to format the changelog for TT-Forums https://git.io/JfRax 14:40:26 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on pull request #143: Add: Script to format the changelog for TT-Forums https://git.io/JfEdq 14:41:38 *** supermop_Home_ has quit IRC 14:45:38 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on issue #147: Metric speed values are still slightly off https://git.io/JfEBi 14:45:53 <DorpsGek_III> [OpenTTD/nml] matthijskooijman commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq 14:47:42 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfEdz 14:48:58 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfE5M 14:49:18 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfE5M 14:55:54 *** iSoSyS has joined #openttd 14:58:52 <Eddi|zuHause> i think i need to do some sanity checks on whatever oberhümer has been doing to this table over the last years 15:18:33 *** cHawk has joined #openttd 15:21:28 <DorpsGek_III> [OpenTTD/OpenGFX] supermop opened issue #44: Open GFX Base Maglev Roofs https://git.io/JfEba 15:22:03 *** supermop_Home has joined #openttd 15:22:11 <supermop_Home> gah 15:22:12 <supermop_Home> ok 15:22:19 <supermop_Home> will i raised an issue 15:22:24 <supermop_Home> well 15:23:24 <supermop_Home> let me know if i did it wrong 15:29:25 <FLHerne> supermop_Home: Some before/after screenshots might be useful? 15:32:24 <supermop_Home> hmm i'm not sure how to get the sprite in game 15:33:00 <supermop_Home> i guess i could just photoshop it 15:41:12 <FLHerne> Eh, nevermind then 15:42:14 *** Flygon has quit IRC 15:42:36 <FLHerne> supermop_Home: Ideally, upload a diff of the spritesheet you've modified 15:42:44 <FLHerne> Or just the entire modified one 15:45:40 <supermop_Home> in this case its the infra08 file - so upload the whole png with these sprites changes right? 15:50:03 *** cHawk- has joined #openttd 15:50:04 <FLHerne> Yes 15:50:32 <FLHerne> Otherwise anyone who wants to try it out has to manually copy your changes back into the right place, which is kind of a pain 15:53:23 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl opened pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAk 15:53:57 <_dp_> ez way to plant 20mil trees ;) 15:55:47 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro requested changes for pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAq 15:56:08 *** cHawk has quit IRC 15:56:50 <Eddi|zuHause> they changed something in google docs, i can't seem to copy-paste from one table to the other anymore 15:57:32 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAk 15:57:54 <LordAro> i wish GH was more consistent in automatically dismissing reviews 15:58:06 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro dismissed a review for pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAq 16:01:05 <glx> yeah a push dismiss approve, but not requested changes 16:01:10 <supermop_Home> FLHerne do i need to name my modified file the same as the original? 16:01:46 <LordAro> supermop_Home: if you're making a PR, yes 16:01:56 <LordAro> because otherwise the actual source code needs changes 16:02:03 <LordAro> just like making a GRF 16:03:32 <supermop_Home> ugh how do i now show the entire image when attaching it to my issue 16:04:12 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAk 16:05:45 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl commented on pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAK 16:06:51 *** Speeder__ has joined #openttd 16:13:33 *** Speeder_ has quit IRC 16:13:34 *** Borg has joined #openttd 16:14:21 <DorpsGek_III> [OpenTTD/OpenGFX] supermop commented on issue #44: Open GFX Base Maglev Roofs https://git.io/JfEba 16:14:57 <_dp_> oh, another default industry adjustment grf conflict :p https://www.tt-forums.net/viewtopic.php?f=32&t=87053 16:29:03 *** nielsm has joined #openttd 16:39:41 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfEpt 16:57:45 *** Wolf01 has joined #openttd 16:58:23 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfE5M 17:26:19 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEjL 17:45:53 <DorpsGek_III> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/Jfuek 17:45:53 <DorpsGek_III> - Update: Translations from eints (by translators) 17:54:57 *** Progman has joined #openttd 17:56:22 *** andythenorth has joined #openttd 17:57:08 <andythenorth> random things 17:57:34 <andythenorth> this is a model of a truck that used to live near my school https://www.ebay.co.uk/itm/B-T-MODELS-BASE-TOYS-1-76-Scale-OO-Gauge-Leyland-Roadtrain-Oxford-JCB-3CX/164194909470 18:00:41 <Eddi|zuHause> but it's not 1:87 18:01:48 <andythenorth> zoom out a bit 18:01:50 <andythenorth> it might be :P 18:15:49 *** Borg has quit IRC 18:17:45 <DorpsGek_III> [OpenTTD/OpenGFX] Andrew350 commented on issue #44: Open GFX Base Maglev Roofs https://git.io/JfEba 18:21:19 *** iSoSyS has quit IRC 18:29:33 *** frosch123 has joined #openttd 18:32:24 <DorpsGek_III> [OpenTTD/OpenGFX] supermop commented on issue #44: Open GFX Base Maglev Roofs https://git.io/JfEba 18:32:34 <FLHerne> supermop_Home: Hm, looking at your sprites I think we have different ideas of how that roof works :p 18:33:06 <FLHerne> supermop_Home: I've always pictured it as a series of arches perpendicular to the track 18:33:22 <FLHerne> And the longitudinal "beams" being catenaries in tension hanging between them 18:33:43 <FLHerne> (the ones that are blue in the original sprite) 18:34:15 <FLHerne> I think the original sprite makes structural sense that way, although the arches could be a bit thicker 18:34:28 <supermop_Home> there are a few structural issues with how it was drawn originally, 18:35:01 <supermop_Home> and it was ambiguous whether it was meant to be a tensile structure or a spaceframe 18:35:12 <FLHerne> Hm. To be clearer: 18:35:27 <supermop_Home> but it was much too vacuous to work as either 18:35:27 <FLHerne> - Cross-wise arches originating from pillars, in compression 18:35:42 <FLHerne> - Longitudinal catenaries between those arches, in tension 18:36:04 <FLHerne> Arch-shaped stringers, crosswise, not really sure :p 18:36:14 <FLHerne> But hanging on the catenaries 18:36:55 <FLHerne> Whereas tbh I don't really see how your new one works, it's a bit thin and a very weird shape for a space-frame 18:37:22 *** adikt has quit IRC 18:37:24 <supermop_Home> FLHerne the 'glass' part doesn't really work in that tensile version 18:38:10 <supermop_Home> and the parts where it droops down at the side are also kinda odd 18:38:55 <supermop_Home> thin it is but i was looking for the most expedient way to make the shape of the original sprite look more substantial 18:40:16 <Wolf01> https://img-9gag-fun.9cache.com/photo/a6KyppN_460s.jpg andythenorth: you could do this in chemtown grf 18:40:23 <supermop_Home> i think the side 'droops' should be inverted, but that's a bigger change 18:41:30 <supermop_Home> the monorail roof makes a lot more sense as a catenary to me 18:43:40 <supermop_Home> i think it may make sense or look better to subdivide the glazed panels a bit more too 18:44:42 <DorpsGek_III> [OpenTTD/OpenGFX] Andrew350 commented on issue #44: Open GFX Base Maglev Roofs https://git.io/JfEba 18:50:39 <Eddi|zuHause> Wolf01: anything after "ethanol" really doesn't sound like anything you'd want in your body in meaningful quantities 18:52:13 <Wolf01> At least not "pure" 19:00:59 <Eddi|zuHause> well, my basic school cemistry taught me "don't ingest any -ol besides ethanol" and "anything containing the word 'benzene' is probably higly cancerous" 19:01:35 <Wolf01> Probably if you mix them they get different names 19:02:37 <Eddi|zuHause> i still haven't learned the "new" print syntax in python3 19:12:00 *** Progman has quit IRC 19:13:19 <frosch123> Eddi|zuHause: chemistry sorts elements into two categories: "cancerous" and "probably cancerous" 19:14:07 <Eddi|zuHause> yeah, it was different back then... 19:14:29 <Eddi|zuHause> when "cancerous" actually meant something 19:16:54 <frosch123> Eddi|zuHause: which new syntax? the one added 15 years ago with "{}".format(foo), or the one added 4 years ago with f"{foo}"? 19:17:24 <Eddi|zuHause> no, the one where "print foo" became "print(foo)" 19:18:29 *** Wormnest has quit IRC 19:24:11 <FLHerne> Eddi|zuHause: The "new syntax" isn't new syntax, it's just an ordinary function call 19:24:40 <FLHerne> It's just that the weird old syntax doesn't exist anymore 19:24:59 <Eddi|zuHause> yes, that is precisely "new syntax" 19:25:50 <FLHerne> There's no syntax that wasn't already there :p 19:28:59 <Eddi|zuHause> no, they changed a completely different syntax for a new purpose. that is new syntax 19:29:38 <Eddi|zuHause> if you compare the parser output, it's completely different, ergo new. 19:32:09 *** WormnestAndroid has quit IRC 19:32:21 *** WormnestAndroid has joined #openttd 19:36:17 <andythenorth> Wolf01 I might include dihydrogen monoxide 19:36:28 <andythenorth> it's fatal if ingested in large quantities 19:36:34 <andythenorth> but desert towns could require it 19:36:39 <frosch123> it's also fatal when pure 19:37:33 <nielsm> it plays a core part in nuclear power plants 19:39:01 <andythenorth> the solid form can be incredibly dangerous 19:39:32 <andythenorth> and the gas 19:40:21 <FLHerne> Eddi|zuHause: The new print() is quite literally just a function call, the syntax for that is the same and used for the same purpose 19:40:48 <FLHerne> The new `print()` builtin is a semantic change, not a syntactic one 19:41:13 <nielsm> more than 300,000 deaths a year are caused by dihydrogen monoxide induced asphyxiation 19:41:53 <frosch123> eddi is basically made of it 19:43:55 <Eddi|zuHause> yeah, i like living on the edge 19:45:32 <Eddi|zuHause> FLHerne: why are you trying to convince me that changing "print" from being a statement to being a function is not a syntax change? 19:46:02 <FLHerne> It's a syntax change, but it's not new syntax :p 19:46:25 <FLHerne> No-one will ever have an excuse to call me not-pedantic... 19:46:52 <Eddi|zuHause> "change" implies "old" turned into "new". 19:48:18 <FLHerne> It's only a removal of the old syntax, there's nothing new 19:49:17 *** nielsm has quit IRC 19:49:19 <FLHerne> You can trivially implement the `print()` function, and call it in the same way with the same syntax, in any version of Python back to the very start 19:50:16 <Eddi|zuHause> why would anyone do that? you can literally use the new syntax and it happens to work on the old syntax 19:51:08 <Eddi|zuHause> because () around an expression is a no-op 19:51:36 <FLHerne> The new builtin takes a bunch of optional arguments for various things 19:52:09 <FLHerne> That the old syntax either couldn't represent, or used very strange extra syntax for 19:54:21 <Eddi|zuHause> none of that, however, changes my habit of writing "print foo" and then wondering why it doesn't work 19:54:46 <andythenorth> took me a while 20:02:59 *** matt21347 has quit IRC 20:09:12 <supermop_Home> hows it going andythenorth 20:10:11 <andythenorth> not bad 20:13:02 <supermop_Home> yay 20:13:28 <supermop_Home> well i dropped / cracked my phone 20:14:24 *** frosch123 has quit IRC 20:25:41 <Eddi|zuHause> get a dumbphone, never worry about dropping or cracking 20:36:27 *** sla_ro|master has quit IRC 20:50:29 *** WormnestAndroid has quit IRC 20:51:32 *** WormnestAndroid has joined #openttd 21:13:01 <Samu> wow, a PR about trees 21:18:19 *** andythenorth has quit IRC 21:22:50 *** michi_cc has quit IRC 21:25:05 *** Wolf01 has quit IRC 21:26:07 *** Wormnest has joined #openttd 21:27:40 <Samu> cyas goodnight 21:27:46 *** Samu has quit IRC 21:37:13 *** michi_cc has joined #openttd 21:37:13 *** ChanServ sets mode: +v michi_cc 21:39:47 *** Progman has joined #openttd 21:43:33 *** gnu_jj has joined #openttd 21:45:58 *** michi_cc has quit IRC 21:46:02 *** michi_cc has joined #openttd 21:46:02 *** ChanServ sets mode: +v michi_cc 21:49:39 *** sla_ro|master has joined #openttd 22:04:06 *** Progman has quit IRC 22:17:46 *** spnda has joined #openttd 22:17:55 <spnda> Hey guys, anyone know where sprite 681 is used? 22:18:01 *** matt21347 has joined #openttd 22:20:50 <FLHerne> spnda: Be aware the answer might be "nowhere", a few sprites in the baseset aren't 22:21:38 <spnda> yeah i think thats whats happening 22:22:35 <FLHerne> spnda: Hm, 681 is a Ç ? 22:22:44 <FLHerne> Or am I looking in the wrong file? 22:22:55 <spnda> 681 is a trash can 22:23:41 <spnda> I don't see it referenced in sprites.h, so it might be just completely unused 22:25:05 <FLHerne> In what file is 681 a trash can? 22:26:12 <spnda> if you look it up in the sprite aligner tool inside openttd and go to sprite 681, thats what comes up 22:26:16 <FLHerne> Searching OpenGFX source I get a large-font 'Ç' and a Toyland RV, neither of which are that 22:26:52 <spnda> https://cdn.discordapp.com/attachments/442748131898032138/712068699623784530/unknown.png 22:27:24 <FLHerne> Ok, I see it in-game, perhaps I'm searching wrong 22:29:43 <FLHerne> Can't think of ever seeing that anywhere 22:31:41 <FLHerne> I wondered if it might be in the scenario editor, that has a few different UI elements 22:31:51 <FLHerne> But I can't see it there either 22:44:09 <supermop_Home> it's a cute trash can 22:47:28 <orudge> So, pleasingly, desktop OpenTTD cross-compiles to ARM64 then runs absolutely fine on an ARM64 Windows 10 device (well, QEMU'd ARM64 device at present). And performance of OpenTTD itself is surprisingly decent in QEMU, admittedly on a 64x64 map! 22:47:35 <orudge> Trying it out on a Raspberry Pi 4 might be more fun though 22:48:23 <TrueBrain> do I dare to ask the big question.... why?! 22:48:30 <orudge> Whyever not :D 22:48:32 <TrueBrain> you bored because of the corona shit? :D 22:48:43 <orudge> I've also been resuccitating the OS/2 port with CMake support... 22:48:54 <TrueBrain> you crazy :P 22:49:00 <TrueBrain> but I like crazy :D 22:49:34 <TrueBrain> off to bed now :) Sleep well all 22:50:12 <orudge> To be fair, the ARM64 Windows port was just a case of installing packages with vcpkg, adding a new target in the VC project, and fixing one bug in a .cpp file. I'll submit a pull request once the cmake changes are in. 22:50:16 <orudge> Heh 22:50:18 <orudge> Night night 22:58:38 *** matt21347 has quit IRC 22:59:23 *** sla_ro|master has quit IRC 23:01:26 <FLHerne> orudge: Can you make it run on MacOS 7? :D 23:01:56 <FLHerne> I got it to run on my Powerbook with Linux installed, but the nubus-pmac kernel fork seems dead for years now 23:03:22 <FLHerne> Perhaps I should try and get that thing working again 23:03:39 <FLHerne> I think the power supply died 23:09:05 *** gelignite has quit IRC 23:22:10 *** tokai|noir has joined #openttd 23:22:10 *** ChanServ sets mode: +v tokai|noir 23:25:45 <Eddi|zuHause> <spnda> https://cdn.discordapp.com/attachments/442748131898032138/712068699623784530/unknown.png <-- that's probably some kind of GUI button 23:25:54 <Speeder__> see if I got it right: coordinate 0, 0 IS present ingame, but represents a vertex, not a tile? 23:26:15 <Eddi|zuHause> Speeder__: that depends 23:26:23 <Speeder__> depends on what? 23:27:08 <Eddi|zuHause> on whether you view vertexes (like the terraform tool) or tiles (like the bulldozer), every tile is represented by its upper (north) corner 23:27:27 *** spnda has quit IRC 23:28:23 <Eddi|zuHause> also, some tiles along the map border might be "void" tiles that aren't visually on the map, but hidden markers of the border (depends on whether you have water borders or freeform borders) 23:29:04 *** tokai has quit IRC 23:29:13 <Speeder__> alright... so, I have a 2048x2048 map 23:29:31 <Speeder__> but in-game using the ? tool, the smallest coordinate is 1x1, and biggest is 2046x2046 23:30:03 <glx> void tiles all around the map used as safety markers IIRC 23:30:33 <Speeder__> but when I export a heightmap of a map that is just a flat square except I modified the outermost tiles (for example making them 1 level lower or higher), the exported heightmap has the border being 2 tiles thick on the "south" side, and 3 tiles thick on the "north" side 23:32:03 <Speeder__> inded, I can't use ? tool on 0x0 23:32:16 <Speeder__> but if I am using the terraform tool, I can make a slope on the first tile 23:32:26 <Speeder__> so I assume the coordinate of 0x0 IS present 23:32:35 <glx> freeform edges 23:32:39 <Speeder__> thus 0x0 exists, you just can't interact with it, except with vertex manipulation tools 23:41:26 *** Speedy` has joined #openttd 23:45:41 <Eddi|zuHause> yes-ish. if you terraform the 1x1 vertex, it modifies the slope on all adjacent tiles (1,1),(1,0),(0,1) and (0,0) 23:47:21 <Eddi|zuHause> that's one of the reasons why there needs to be a row of void tiles: so the terraform tool doesn't crash (or do weird things) when you modify the border of the map 23:48:54 <Eddi|zuHause> if you have freeform borders on, then you have 2046 tiles or 2047 vertices accessible on a 2048 map. means there is 2 inaccessible tiles and 1 inaccessible vertex 23:50:07 <Eddi|zuHause> if you have fixed water borders active, you get 1 additional tile, but you lose the ability to terraform 1 vertex 23:51:22 <Speeder__> loading heightmap I assume is always "freeform" mode? 23:53:24 <Eddi|zuHause> no, i think you can set that up 23:54:40 <Speeder__> so, in a heightmap file... pixel 0x0 is a vertex, outside the map. pixel 1x1, and pixel 2047x2047, are whole tiles, but that are "void tiles", kinda outside the map? 23:56:23 <Eddi|zuHause> no 23:57:21 <Eddi|zuHause> pixel 0x0 is both a void tile and an "outside" vertex, 1x1 is a real tile, and 2047x2047 is a void tile, but a real vertex 23:59:44 <Eddi|zuHause> 2047x2047 must be a real vertex, because it still affects the slope on the real tile 2046x2046