IRC logs for #openttd on OFTC at 2019-11-24
⏴ go to previous day
00:10:04 *** supermop_work_ has quit IRC
00:10:26 *** supermop_work_ has joined #openttd
00:40:40 *** supermop_work_ has quit IRC
00:41:40 *** supermop_work_ has joined #openttd
00:50:47 *** snail_UES_ has joined #openttd
01:11:54 *** supermop_work_ has quit IRC
01:12:27 *** supermop_work_ has joined #openttd
01:42:41 *** supermop_work_ has quit IRC
01:44:27 *** supermop_work_ has joined #openttd
01:54:37 *** Smedles has joined #openttd
02:14:41 *** supermop_work_ has quit IRC
02:16:28 *** supermop_work_ has joined #openttd
02:48:12 *** supermop_work_ has quit IRC
02:50:28 *** supermop_work_ has joined #openttd
03:20:43 *** supermop_work_ has quit IRC
03:21:47 *** supermop_work_ has joined #openttd
03:33:09 *** Wormnest has joined #openttd
03:39:39 *** Wormnest_ has joined #openttd
03:52:03 *** supermop_work_ has quit IRC
03:52:29 *** supermop_work_ has joined #openttd
04:22:44 *** supermop_work_ has quit IRC
04:24:31 *** supermop_work_ has joined #openttd
04:41:11 *** ChanServ sets mode: +v tokai
04:49:02 *** snail_UES_ is now known as Guest8634
04:49:02 *** snail_UES_ has joined #openttd
04:54:44 *** supermop_work_ has quit IRC
04:56:30 *** supermop_work_ has joined #openttd
05:26:45 *** supermop_work_ has quit IRC
05:28:25 *** supermop_work_ has joined #openttd
05:39:50 *** daspork has joined #openttd
05:43:57 <Eddi|zuHause> oh, you can order transport fever 2 now (for -25% if you own the previous game)
05:45:19 *** Wormnest_ has joined #openttd
05:58:40 *** supermop_work_ has quit IRC
06:00:33 *** supermop_work_ has joined #openttd
06:30:46 *** supermop_work_ has quit IRC
06:31:52 *** supermop_work_ has joined #openttd
06:47:28 *** daspork has joined #openttd
07:02:07 *** supermop_work_ has quit IRC
07:02:53 *** supermop_work_ has joined #openttd
07:33:07 *** supermop_work_ has quit IRC
07:33:54 *** supermop_work_ has joined #openttd
07:43:43 *** sla_ro|master has joined #openttd
07:46:39 *** FLHerne has joined #openttd
07:53:06 *** Eddi|zuHause2 has joined #openttd
07:56:34 *** ZirconiumY has joined #openttd
07:57:54 *** WormnestAndroid has quit IRC
07:58:56 *** Ammller has joined #openttd
07:59:06 *** nolep[m]1 has joined #openttd
07:59:43 *** seatsea0419211 has joined #openttd
07:59:50 *** WormnestAndroid has joined #openttd
08:00:29 *** Hobbyboy|BNC has joined #openttd
08:02:08 *** ist5shreawf[m] has quit IRC
08:02:09 *** dag[m]1 has joined #openttd
08:02:10 *** Ammller is now known as Ammler
08:02:10 *** Heili is now known as Heiki
08:03:26 *** XeryusTC has joined #openttd
08:03:45 *** tyteen4a03 has joined #openttd
08:04:08 *** supermop_work_ has quit IRC
08:05:03 *** peter1138 has joined #openttd
08:05:03 *** ChanServ sets mode: +o peter1138
08:05:06 *** grossing has joined #openttd
08:05:44 *** Darkvater has joined #openttd
08:05:44 *** ChanServ sets mode: +o Darkvater
08:05:53 *** supermop_work_ has joined #openttd
08:13:01 *** joey[m] has joined #openttd
08:16:24 *** argoneus has joined #openttd
08:25:51 *** patricia[m] has joined #openttd
08:30:56 *** yoltid[m] has joined #openttd
08:32:26 *** iarp[m] has joined #openttd
08:35:09 *** andythenorth has joined #openttd
08:36:08 *** supermop_work_ has quit IRC
08:37:54 *** supermop_work_ has joined #openttd
08:37:55 *** johanna[m] has joined #openttd
08:39:36 <DorpsGek_III> [OpenTTD/nml] andythenorth commented on pull request #59: Simplify pillow imports and version detection https://git.io/Jei54
08:46:49 <LordAro> needs glx to look into
08:47:07 <LordAro> (also, nml uses GH actions, not azure)
08:47:22 <LordAro> (though they're almost certainly running on the same thing)
08:48:34 <LordAro> it seems like it's just not actually started (yet?)
08:49:10 <LordAro> oh, derp - yeah, this comes from before Actions were added
08:57:20 *** glothit7ok[m] has joined #openttd
09:08:09 *** supermop_work_ has quit IRC
09:08:35 *** supermop_work_ has joined #openttd
09:17:54 *** backtu[m] has joined #openttd
09:27:18 *** Progman has joined #openttd
09:38:50 *** supermop_work_ has quit IRC
09:39:15 *** supermop_work_ has joined #openttd
10:03:46 *** tops[m] has joined #openttd
10:09:30 *** supermop_work_ has quit IRC
10:09:56 *** supermop_work_ has joined #openttd
10:39:38 *** buggeas40d[m] has joined #openttd
10:40:11 *** supermop_work_ has quit IRC
10:40:36 *** supermop_work_ has joined #openttd
11:10:51 *** supermop_work_ has quit IRC
11:11:58 *** supermop_work_ has joined #openttd
11:40:06 *** khavik[m] has joined #openttd
11:40:53 <andythenorth> 1CC or 2CC for the tech tree?
11:41:27 <andythenorth> 1CC is much tidier and has the advantage that all trains look the same
11:42:13 *** supermop_work_ has quit IRC
11:42:38 *** supermop_work_ has joined #openttd
12:12:52 *** supermop_work_ has quit IRC
12:14:40 *** supermop_work_ has joined #openttd
12:44:53 *** supermop_work_ has quit IRC
12:45:30 *** supermop_work_ has joined #openttd
13:15:45 *** supermop_work_ has quit IRC
13:16:31 *** Eddi|zuHause2 is now known as Eddi|zuHause
13:16:39 *** supermop_work_ has joined #openttd
13:33:54 *** planetmaker has joined #openttd
13:33:54 *** ChanServ sets mode: +o planetmaker
13:46:54 *** supermop_work_ has quit IRC
13:47:37 *** supermop_work_ has joined #openttd
14:17:52 *** supermop_work_ has quit IRC
14:18:41 *** supermop_work_ has joined #openttd
14:42:51 <Eddi|zuHause> rationality died like 3 years ago
14:48:21 *** Hirundo has joined #openttd
14:48:55 *** supermop_work_ has quit IRC
14:49:50 *** supermop_work_ has joined #openttd
14:53:56 <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #60: Avoid duplicating rail/road/tramtype table code https://git.io/Jeipa
15:02:57 <DorpsGek_III> [OpenTTD/nml] FLHerne dismissed a review for pull request #60: Avoid duplicating rail/road/tramtype table code https://git.io/JeiaJ
15:02:58 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #60: Avoid duplicating rail/road/tramtype table code https://git.io/JeKFk
15:20:05 *** supermop_work_ has quit IRC
15:20:42 *** supermop_work_ has joined #openttd
15:22:10 <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #60: Avoid duplicating rail/road/tramtype table code https://git.io/JeipS
15:38:38 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #60: Avoid duplicating rail/road/tramtype table code https://git.io/JeKFk
15:40:39 <glx> it was not easy to connect today
15:41:15 <glx> had to put the ip manually
15:41:46 <Eddi|zuHause> always have backup DNS servers...
15:42:10 <glx> I was always sent on a full server
15:42:30 <glx> so immediate closing of the connection
15:42:39 <FLHerne> At least we're not on SlashNet
15:42:59 <Eddi|zuHause> so malfunctioning load balancer?
15:43:12 <glx> I tried webchat and I was on an orphan server it seems
15:43:44 <FLHerne> (their DNS has been down for a couple of days, so everyone has to connect via IP or alternate domains)
15:43:49 <Eddi|zuHause> you can set up your client to try different servers directly, instead of the generic one
15:45:26 <glx> I tried that but only via IPv6, should have test IPv4 too
15:48:13 <glx> btw FLHerne your other PR will need a rebase too (sorry for that)
15:49:22 <DorpsGek_III> [OpenTTD/nml] FLHerne dismissed a review for pull request #63: Allow PLY to generate parsing/lexing tables. https://git.io/Jei25
15:50:57 *** supermop_work_ has quit IRC
15:52:42 *** supermop_work_ has joined #openttd
15:53:31 <LordAro> we're not concerned about commit messages for NML, are we?
15:53:38 <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #59: Simplify pillow imports and version detection https://git.io/Jeihk
15:54:00 <glx> there's no commit checker for now
15:54:31 <LordAro> i added a "Codechange:"
15:59:51 <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #35: Fix ottd_display_speed to reflect changes done in OpenTTD https://git.io/Jeihq
16:01:46 <glx> ah regression testing works very well :)
16:02:26 <glx> looks like failed conflict resolution Eddi|zuHause
16:02:53 <Eddi|zuHause> yeah, i forgot to remove a line
16:04:53 *** WormnestAndroid has quit IRC
16:06:02 <Eddi|zuHause> this giant import line is a bit unwieldy
16:07:26 <FLHerne> Eddi|zuHause: It looks as though it was sorted alphabetically, once?
16:07:41 <FLHerne> Probably worth re-establishing that
16:08:20 <Eddi|zuHause> FLHerne: that wouldn't solve the conflicty-ness of the line
16:08:24 *** Hazzard has joined #openttd
16:08:41 <FLHerne> Add a few linebreaks?
16:08:58 <glx> yeah the line could be split
16:09:34 <FLHerne> You can do `from foo import (aaa, bbb, ccc, \n ddd, eee)`
16:10:03 <Eddi|zuHause> FLHerne: ideally, each module would be on a separate line
16:10:19 <FLHerne> Why? that would be a lot of lines
16:10:39 <Eddi|zuHause> we're not having a shortage of available lines
16:11:51 <FLHerne> I do wonder if a separate `comment()` thing is right
16:12:28 <FLHerne> How is that semantically different from an actual comment?
16:12:54 <FLHerne> (forgetting the parser implementation for now)
16:13:45 <Eddi|zuHause> FLHerne: the comment will be embedded in the resulting grf
16:13:59 <Eddi|zuHause> i need that for further post-processing
16:14:04 <Eddi|zuHause> ... which is a major hack
16:14:31 <Eddi|zuHause> glx: i wonder if that file got lost, or never was there in the first place
16:15:09 <FLHerne> But if we're putting comments into the grf for readability, then we should just put the actual comments in the grf
16:15:24 <Eddi|zuHause> yeah, i found it... in my old hg checkout
16:15:36 <FLHerne> I suppose major hacks are different, but is that the right thing to do?
16:15:58 <glx> -a---- 19/10/2019 22:12 7003 030_house.nml
16:15:58 <glx> -a---- 19/10/2019 22:12 628 031_aircraft.nml
16:15:58 <glx> -a---- 19/10/2019 22:12 769 032_simple_house.nml
16:16:01 <Eddi|zuHause> FLHerne: i guess that question is the reason why it was never included
16:16:40 <Eddi|zuHause> glx: well, it should be added by my patch
16:17:01 * FLHerne was trying to figure out how to attach comments to the relevant syntax element in NML, mostly so that round-tripping wouldn't eat them
16:17:08 <Eddi|zuHause> glx: also, i should maybe renumber it :)
16:17:14 <FLHerne> (I haven't figured out how to make that not suck yet)
16:17:42 <FLHerne> What hack is it intended for?
16:18:15 <glx> action 0C comments are mainly for grf decompilation
16:19:24 <FLHerne> Ok, but for nml-generated grfs that doesn't seem useful
16:19:35 <Eddi|zuHause> FLHerne: i compile multiple grfs, and then cut out certain lines to combine them
16:20:44 <Eddi|zuHause> so i have multiple grfs of the format "<head><body><tail>", and want a resulting GRF containing <head><body1><body2><body...>
16:21:03 <Eddi|zuHause> so i need a recognizable pattern for "head ends here" and "tail starts here"
16:21:18 <Eddi|zuHause> that's what i use the actionC for
16:22:20 <Eddi|zuHause> it... works... but is not very elegant
16:22:39 <FLHerne> Wouldn't sticking the nml together like all andy's templates make more sense?
16:22:48 <FLHerne> Oh, you have stations or something?
16:22:57 *** supermop_work_ has quit IRC
16:23:10 <Eddi|zuHause> FLHerne: compiling the full grf in one go tended to crash from memory explosion in parsing
16:23:27 <FLHerne> That sounds like the bug to fix :P
16:24:14 <Eddi|zuHause> i guess the root of that problem is python's string handling, where modifying a string results in a full copy of the string
16:24:19 *** supermop_work_ has joined #openttd
16:24:24 <Eddi|zuHause> but i've never gone anywhere on debugging that
16:24:34 <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #65: Fix #57: Check coherency of GRF parameters limits https://git.io/Jei6E
16:24:41 <FLHerne> I did have some ideas for speeding that up
16:25:28 <Eddi|zuHause> FLHerne: the main problem with that is that this would be inside lex/yacc code, and not nml itself
16:25:45 <FLHerne> Some sort of pre-parsing pass to split the input into blocks before giving it to the parser would probably help
16:26:14 *** WormnestAndroid has joined #openttd
16:26:30 <Eddi|zuHause> FLHerne: we're talking about some 100k lines of nml code here
16:26:51 <FLHerne> I think that means your grf is too big, but yes
16:27:13 <FLHerne> Oh, I was meaning to ask
16:27:20 <Eddi|zuHause> FLHerne: well, the generator is about 1k lines, and the vehicle table is another 1k lines... :)
16:27:30 <FLHerne> Does the line_directive import stuff in the parser actually work?
16:27:35 <FLHerne> I've never seen it used
16:28:44 <FLHerne> (or did I just completely fail to understand what that's about)
16:29:17 <Eddi|zuHause> i've no clue what you're talking about
16:29:41 <FLHerne> Oh, I see what it's for
16:30:34 <FLHerne> The parser understands directives of the form `#line linenum file`, so a preprocessor can tell it where the lines originally came from
16:31:04 <FLHerne> And the error output will show that instead of the original filename/linenumbering
16:31:11 <Eddi|zuHause> yes, that's for if you combine files via #include, the line can be traced back to the original file for error messages
16:32:13 <FLHerne> But it doesn't do the #include-ing itself, so that's no use for parsing the input in manageable chunks
16:32:15 <Eddi|zuHause> i think there's enough people using that so we would have heard about when it's not working
16:32:38 <Eddi|zuHause> FLHerne: no, all the #include-s are resolved before parsing
16:33:11 <FLHerne> Imprlementing a native #include that parsed the linked file separately would probably help
16:33:53 <Eddi|zuHause> yeah. we talked about that before, but that didn't sound like a project i was likely to tackle at any point
16:35:03 <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #65: Fix #57: Check coherency of GRF parameters limits https://git.io/Jei6E
16:35:07 <Eddi|zuHause> (also, this would not adress the second part that my approach does, which is running several nmlc instances in parallel)
16:35:58 <FLHerne> Andy was suggesting that nmlc should use multiprocessing only the other day :P
16:36:01 <Eddi|zuHause> (the only single-thread bottleneck in my build process is grfcodec, which still takes significant amounts of time)
16:36:06 <glx> ah you parse many nml files then merge the nfo
16:36:40 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7842: Crash on one my save in every version of OpenTTD https://git.io/Jeig0
16:38:11 <Eddi|zuHause> i think my last timing was like: complete build process (6 jobs in parallel) was 2 minutes, 1 minute of which was in grfcodec. and unfolding the parallel parts would result in 5 minutes total
16:41:11 <Eddi|zuHause> <FLHerne> Andy was suggesting that nmlc should use multiprocessing only the other day :P <-- yeah, but i don't see how that could be accomplished
16:42:40 <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #65: Fix #57: Check coherency of GRF parameters limits https://git.io/JeijL
16:45:52 *** Terkhen has joined #openttd
16:45:52 *** ChanServ sets mode: +o Terkhen
16:46:11 *** XeryusTC has joined #openttd
16:47:22 *** V453000 has joined #openttd
16:48:18 <andythenorth> what happens in the parse step?
16:49:09 <andythenorth> it's relatively slow....
16:49:15 <Eddi|zuHause> andythenorth: how many years of computer science education do i have to give you before starting compiler construction 1 lecture? :p
16:49:22 *** fonsinchen has joined #openttd
16:49:36 *** ^Spike^ has joined #openttd
16:49:46 <andythenorth> just explain what it does in 3 lines, and we'll see how close my assumption was
16:50:23 <DorpsGek_III> [OpenTTD/OpenTTD] James103 commented on issue #7842: Linkgraph takes a very long time to recalculate on large save, causing hangs https://git.io/Jeig0
16:52:19 <andythenorth> or to put it another way, can an AST be constructed using multiple workers, similar to map:reduce?
16:52:26 <andythenorth> or is it fundamentally a single-worked process?
16:53:21 <andythenorth> hmm nmlc doesn't report how long the lexing takes
16:54:06 <Eddi|zuHause> andythenorth: typically it has to go through the file character by character, exactly once.
16:54:17 <andythenorth> maybe that's all inside parser.py, and reported as one timing
16:54:33 *** supermop_work_ has quit IRC
16:54:54 <andythenorth> maybe I can insert more timing
16:55:02 <Eddi|zuHause> andythenorth: lexing is typically a pipe, so might be tricky to single out the timing
16:55:47 <andythenorth> ok I'm not specifically interested in the lexer, just trying to get a handle on what's time consuming
16:55:53 <Eddi|zuHause> lexing reads a character, and tries to decide to put it into the current token, or start a new token
16:56:07 <andythenorth> parsing is 20-30% of a grf compile for me
16:56:43 *** supermop_work_ has joined #openttd
16:57:02 <Eddi|zuHause> i think there could be the problem, because python uses immutable strings, so adding a character to the token makes a copy of the string, instead of modifying it inplace
16:58:19 <Eddi|zuHause> it's not really THAT slow of an operation, but it could result in the memory explosion that i was experiencing
16:58:45 *** HerzogDeXtEr has joined #openttd
16:59:04 <andythenorth> unrelated: Iron Horse compiled grf is now ridiculously large
16:59:23 <andythenorth> OpenTTD is 7.5MB
17:00:39 <andythenorth> there are 93000 instances of this path 'generated/graphics/'
17:01:04 <andythenorth> the generated nfo is 17.9MB which seems insane
17:01:16 <LordAro> does the nfo contain the paths?
17:01:16 <andythenorth> the actual png files are only 4.3MB
17:01:25 <andythenorth> yes the nfo contains the paths
17:01:51 <andythenorth> the nml is 10.7MB, so nml is somehow more efficient
17:02:04 <LordAro> @calc 93000 * (19 - 4)
17:02:16 <LordAro> well you could remove 1MB by replacing the path to be g/g/ :p
17:02:16 <DorpsGek_III> [OpenTTD/OpenTTD] Awizonosz commented on issue #7842: Linkgraph takes a very long time to recalculate on large save, causing hangs https://git.io/Jeig0
17:02:26 <Eddi|zuHause> andythenorth: impressive, CETS is only 11MB
17:02:36 <andythenorth> presumably the final grf doesn't include the image paths though
17:02:41 <FLHerne> andythenorth: The problem is that it's an LR parser
17:03:07 <FLHerne> Or LALR? something-rightmost, anyway
17:03:23 <Eddi|zuHause> FLHerne: almost all compilers ever are LALR(1)
17:03:24 <LordAro> andythenorth: you can run `strings` on the grf to see what text it contains
17:03:25 <andythenorth> at this filesize, Iron Horse needs splitting into separate grfs
17:03:31 <andythenorth> or I need to redesign it
17:03:57 <FLHerne> Eddi|zuHause: Ok, the problem is that and it's written in Python :P
17:04:00 <andythenorth> LordAro: how? o_O
17:04:10 <LordAro> `strings foo.grf | less`
17:04:32 <LordAro> if it contains the paths repeatedly, that'll show up
17:05:00 <FLHerne> Hm, nevermind, what I was saying is stupid
17:05:19 <Eddi|zuHause> andythenorth: modern games have 30GB patches...
17:05:45 *** frosch123 has joined #openttd
17:06:10 <andythenorth> Eddi|zuHause: true, but there's no need for Horse to be this big
17:06:29 <andythenorth> and it will scale horribly if I add 4 more different rosters in the same grf
17:07:01 <glx> maybe it's the way you organise your stuff in the grf
17:07:16 <Eddi|zuHause> conversation from last night: "i can't play CoD, because of 20GB patch" – "that's just 1/6 of the total game size"
17:07:34 *** WormnestAndroid has quit IRC
17:07:36 <glx> I guess you have a lot of duplication in your nml
17:07:56 <andythenorth> there are hundreds or thousands of almost identical varact 2 chains
17:08:01 *** WormnestAndroid has joined #openttd
17:08:17 <andythenorth> but they end on a different realsprite, and there's no way to pass the target sprite along the chain
17:08:23 <andythenorth> the whole chain has to be duplicated
17:08:28 <Eddi|zuHause> glx: removing duplication is not trivial, as the number of parallel IDs is severely limited
17:08:53 <Eddi|zuHause> also, nml has no support for procedures
17:09:14 <glx> can't set a temporary parameter at the begining of the chain ?
17:09:30 <andythenorth> not to get a realsprite no
17:09:58 <andythenorth> there's no equivalent of "with (spritesheet): long logic chain -> result"
17:10:10 <Eddi|zuHause> you would need a giant switch that contains "all" realsprites
17:10:23 <andythenorth> for every branch of the chain
17:10:28 <andythenorth> the saving would be dubious
17:10:45 <Eddi|zuHause> which would just be a mapping number->realsprite
17:10:46 <andythenorth> I already considered that and rejected it :P
17:11:07 <Eddi|zuHause> that would read the number from the temp parameter
17:11:27 <andythenorth> it would just be the vehicle ID no?
17:12:50 <Eddi|zuHause> if any vehicle had more than one realssprite, it would have to be differentiated there
17:13:08 <Eddi|zuHause> and if it didn't you wouldn't need any varaction2 in the first place
17:13:15 <andythenorth> if we had functions :P
17:13:27 <andythenorth> it could just be a function call, yielding a number, and then switch realsprite on that
17:13:58 <glx> hmm but there are procedure calls
17:14:12 <Eddi|zuHause> glx: there are in nfo, but nml cannot create them
17:14:29 <glx> that's something to add I guess :)
17:14:38 <Eddi|zuHause> i tried to look into it, but got nowhere
17:16:18 *** Wormnest has joined #openttd
17:16:19 <Eddi|zuHause> 9. Sep 2014 nml-hg/nml_call_procedure.diff
17:18:11 <Eddi|zuHause> i _think_ that sort of worked, but you couldn't pass any nml expressions as parameter
17:20:30 <Eddi|zuHause> and parameter would need to be the name of a switch, iirc
17:21:06 <Eddi|zuHause> so you need a param_function that converts the name of a switch to its ID
17:22:21 <Eddi|zuHause> overall, it seems a bit hacky, and there's probably a better syntax
17:23:51 <Eddi|zuHause> i vaguely remember trying a second approach, but can't find any evidence of that
17:26:46 <glx> grf doc is not very clear, I need to check implementation in openttd :)
17:26:58 *** supermop_work_ has quit IRC
17:28:45 *** supermop_work_ has joined #openttd
17:33:49 <glx> for me it's the nfo syntax ;)
17:34:22 <glx> it's not the most human friendly language
17:34:27 <FLHerne> I think NFO docs could do with a summary of what the different action types are for and how they're typically used together
17:34:42 <FLHerne> (unless I've missed it)
17:34:42 <Eddi|zuHause> glx: yeah, it's a little... low level
17:34:56 <andythenorth> action 0, 2, 3, 1
17:35:01 <FLHerne> All the information is /there/ in the individual action docs
17:35:13 <andythenorth> there's probably a tutorial somewhere
17:35:24 <andythenorth> but I've heard this question from too many programmers :)
17:35:41 <andythenorth> I have a feeling that nfo originates in the same place as perl :P
17:35:48 <andythenorth> someone like me, not a programmer
17:35:49 <FLHerne> But to piece together a high-level picture of how they fit together, I have to read all of them, and reading them is hard when I don't know what they're for :P
17:36:06 <Eddi|zuHause> andythenorth: i don't see the connection
17:37:08 <Eddi|zuHause> andythenorth: nfo is very clear and structured, if you come from a ttdpatch mindset
17:37:40 <FLHerne> AAUI, that was the point
17:38:00 <andythenorth> I don't know what my exact point is, but I've seen multiple people struggle to grok nfo
17:38:06 <FLHerne> NFO isn't a language/format created top-down to make logical sense
17:38:10 <andythenorth> there's something non-getttable about it for some programmers
17:38:33 <glx> oh there can be something between <variable> and <varadjust>
17:39:00 <Eddi|zuHause> glx: yeah, i was just looking for where that info is actually written
17:39:02 <FLHerne> It's a bottom-up collection of behaviours that people hacked incrementally into TTDPatch and then OTTD
17:40:11 <glx> "When the variable in a VarAction2 is 7E, the procedure given by the 60+x parameter is invoked." <-- I didn't see where the parameter could be
17:42:06 <Eddi|zuHause> "60+x D similar to 40+x variables, but the variable number must be followed by a byte, which will be given to the variable handler as parameter."
17:42:22 <Eddi|zuHause> it's a bit buried
17:45:37 *** snail_UES_ has joined #openttd
17:48:04 <Eddi|zuHause> btw. do we meanwhile have syntax for 6x vars like var 61?
17:49:02 <Eddi|zuHause> CETS is still using the var[num, shift, mask, param] syntax
17:50:23 <glx> there are many varact2vars60x_
17:50:25 <FLHerne> Basic thing: when the docs say "You can add 80 to the operation number..." etc. I assume that's hex?
17:51:07 <glx> yes this 80 should be hex
17:51:25 <Eddi|zuHause> everything in NFO is hex, except for the sprite number and length
17:51:42 <glx> basically everything is hex unless otherwise specified
17:57:41 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7842: Linkgraph takes a very long time to recalculate on large save, causing hangs https://git.io/Jeig0
17:58:59 *** supermop_work_ has quit IRC
18:00:48 *** supermop_work_ has joined #openttd
18:30:59 *** josef[m]1 has joined #openttd
18:30:59 *** natalie[m] has joined #openttd
18:30:59 *** paulus[m] has joined #openttd
18:30:59 *** dude[m] has joined #openttd
18:30:59 *** ist5shreawf[m] has joined #openttd
18:30:59 *** goodger has joined #openttd
18:32:35 *** gelignite has joined #openttd
19:06:28 *** Progman has joined #openttd
19:32:04 *** pm is now known as planetmaker
19:36:03 *** WormnestAndroid has quit IRC
19:36:22 *** WormnestAndroid has joined #openttd
19:46:39 *** Alkel_U3 has joined #openttd
19:47:00 *** supermop_work_ has quit IRC
19:47:58 *** supermop_work_ has joined #openttd
20:33:10 * andythenorth has spent nearly two days just routing pneumatic pipes :P
20:34:46 <frosch123> irc is tricky to join today
20:35:24 <frosch123> didn't you scale down on lego? or was that wolf?
20:40:21 <andythenorth> I scaled down on Lego
20:40:27 <andythenorth> but there are unfinished things
20:40:33 <andythenorth> [aren't there always?]
20:51:35 *** tokai|noir has joined #openttd
20:51:35 *** ChanServ sets mode: +v tokai|noir
20:56:56 <andythenorth> there's about 4 days of progress between the 2 :P
20:57:12 <andythenorth> lego is even slower than making OpenTTD stuff
21:01:49 <supermop_work_> it's taken be a week to connect a limestone mine to this steel mill
21:02:47 <supermop_work_> get home from work, look at network plot alignment, get unsure how i want junction to look, or what else i want trains to do, give up
21:03:04 *** Wormnest has joined #openttd
21:21:29 <andythenorth> wonder if I could diff the vehicle properties
21:21:54 <andythenorth> if only action 0 is changed, I could modify the generated nfo directly, instead of generating nml then nfo
21:22:04 <andythenorth> I already skip nml if it's only sprites changed
21:30:46 * FLHerne experiments with various ways to improve NML's parsing performance
21:32:52 <andythenorth> move the parse to C++
21:34:46 <glx> (of course the regression change is just for testing)
21:36:39 <glx> added the output in paste comment
21:46:09 <andythenorth> I've never used procedures, so I don't have a good test case trivially
21:46:42 *** supermop_work_ has quit IRC
21:46:56 <andythenorth> can we do a regression test or example for them?
21:47:14 *** supermop_work_ has joined #openttd
21:48:29 <glx> basically you write a swicth or random_switch, and you use its ID as a variable in another switch
21:48:54 <glx> that's how I understand the spec
21:49:00 <andythenorth> yes that makes sense
21:49:20 <glx> I think I need to add some safety checks
21:50:01 <andythenorth> do we know if stored procedures respect temp registers?
21:52:03 <frosch123> they are in the same chain
21:52:28 <frosch123> so nml has to make sure to not use registers in the main chain, which are modified in the procedure
21:52:32 <andythenorth> if I understand them correctly, I might be able to cut down the code surface in some grfs by large amounts
21:52:54 <frosch123> if you have an expression in the procedure, nml will use registers to store intermediate values
21:53:14 <frosch123> if you use the procedure in an expression, that expression may also have temporary values
21:53:33 <frosch123> which probably should not get destroyed by the procedure
21:54:33 <andythenorth> for a given vehicle type, if I can consolidate to a shared varact 2 chain, there might be 40 vehicle instances that can use it
21:54:34 <frosch123> so, wherever nml allocates temporary registers, it needs to keep track of which are modified by procedures
21:57:18 <andythenorth> wonder how long I could spend making it compile faster? o_O
21:58:13 <frosch123> i guess nml could output an intermediate format instead of nfo, so you can somehow invoke it differently if the nml sources dont change
21:58:36 <frosch123> nml sprite encoding with sprite cache and stuff is better than grfcodec after all
21:58:59 <frosch123> so it would be worth it to support the nml+grfcodec split inside nml
21:59:18 <frosch123> without actually using grfcodec or nfo format
22:01:37 <andythenorth> there's an AST or something?
22:01:49 <frosch123> too complicated, just the action list
22:02:14 <frosch123> same info as in nfo, but using json or whatever
22:03:07 <glx> after some testing, I clearly need safety checks
22:03:45 <FLHerne> Dropping line-number tracking knocks 20% off the parse time
22:04:01 <andythenorth> the grfcodec compile for Iron Horse 400k loc is 6s
22:04:20 <andythenorth> teach nml nfo? :P
22:04:23 <FLHerne> Of course, people do like line numbers in their error messages
22:04:38 <andythenorth> I could live with suppressing it FLHerne
22:04:44 <andythenorth> I will then act surprised that they're gone :P
22:04:52 <glx> line number is useful when you have 100k lines :)
22:05:01 <frosch123> andythenorth: nfo is horrible to parse. better use something with python-built-in parsers
22:05:21 <andythenorth> json would also permit evil :P
22:05:23 <FLHerne> I think the right thing would be to count lines up to a given lexpos as and when we need to give an error :P
22:05:39 <andythenorth> I could...for example...just skip the nml step :P
22:06:01 <andythenorth> this could be a good move
22:06:07 <FLHerne> frosch123: I don't see what you're trying to achieve with that
22:06:27 <FLHerne> If the actions haven't changed, why not just keep the NFO?
22:06:29 <frosch123> FLHerne: andy complains about compile time when only changing graphics
22:07:07 <andythenorth> it's not too bad now I added the grfcodec step
22:07:22 <frosch123> when grfcodec takes only 6s for horse, it may not be worth the effort
22:07:42 <frosch123> but for 32bpp grfs nml is multiple times faster than grfcodec with encoding sprites
22:08:39 <FLHerne> frosch123: Oh, so you don't want to /change/ the NFO, but you want to get the realsprite data without (re)parsing the NML?
22:09:31 <frosch123> currently andy makes nml generate nfo, and then used grfcodec for nfo+sprites=grf
22:09:45 <frosch123> then andy skips nml if only sprites change
22:10:13 <frosch123> that split is fine, but it would be even faster if grfcodec was replaced with something using the nml encoding
22:11:12 <andythenorth> it was suprisingly effective strategy
22:11:24 <andythenorth> and a lot less string than previous attempts like partially compiling nml
22:14:28 *** arikover has joined #openttd
22:17:27 *** supermop_work_ has quit IRC
22:18:53 *** supermop_work_ has joined #openttd
22:22:31 <FLHerne> There's no such thing as a multiline string in NML, is there?
22:23:28 <FLHerne> I think the answer is "yes there is" :-/
22:24:10 <frosch123> there are hardly any strings in nml?
22:24:14 <frosch123> not sure what you mean
22:24:39 <FLHerne> ...but that would throw the calculated line number off, so perhaps that's hypothetical if no-one cared
22:25:07 <frosch123> expressions can be split over multiple lines
22:25:29 <frosch123> nml is a token-based language, so linebreaks are like any other whitespace
22:26:15 <FLHerne> The parser doesn't have anything that prevents a literal-string from containing newlines
22:26:44 <FLHerne> It may be that there are no circumstances in which a literal-string is semantically permitted to contain them :P
22:27:11 <FLHerne> In which case there's no problem if I mess those up
22:29:32 * andythenorth is using the Migrations GS
22:29:34 <andythenorth> it's quite interesting
22:29:48 <andythenorth> it builds towns near newly serviced industries and moves population there
22:30:26 <andythenorth> it ruins my industries for transport though, by surrounding them with houses :D
22:30:40 <FLHerne> Answer: yes, you can have newlines in (at least) town names
22:31:12 <frosch123> oh, i forgot town names :)
22:31:20 <frosch123> yeah, they are different to everything else
22:31:32 <frosch123> but i guess newlines are still invalid there
22:31:44 <frosch123> since ottd encodes newlines as \r instead of \n
22:32:36 <frosch123> so if nml actually creates \n in strings, then that is wrong anyway, so you can also forbid it :)
22:33:19 *** karoline[m] has joined #openttd
22:49:04 *** supermop_work_ has quit IRC
22:50:52 *** supermop_work_ has joined #openttd
23:13:18 *** ChanServ sets mode: +v tokai
23:16:57 *** snail_UES_ has joined #openttd
23:21:05 *** supermop_work_ has quit IRC
23:22:53 *** supermop_work_ has joined #openttd
23:45:34 *** WormnestAndroid has quit IRC
23:46:21 *** WormnestAndroid has joined #openttd
23:58:29 *** WormnestAndroid has quit IRC
23:58:53 *** WormnestAndroid has joined #openttd
continue to next day ⏵