IRC logs for #openttd on OFTC at 2020-05-20
⏴ go to previous day
00:12:25 <LordAro> michi_cc: i'd say it's more likely you'd find a system where you could get 14 but not 17
00:17:24 <michi_cc> LordAro: Make a PR, then I'll happily change it to make_unique :D
00:19:44 <LordAro> *merges 7270 out of spite*
00:26:04 <Eddi|zuHause> glx: they're generated somewhere halfway through the make process
00:26:28 <glx> I'm fixing py files used by make process :)
00:27:10 <Eddi|zuHause> what needs fixing?
00:27:23 <glx> I get syntax errors in many places
00:27:31 <Eddi|zuHause> they're python2 files
00:29:21 <glx> but my python is python3, for python2 I need to use python2
00:29:47 <glx> so I still need to fix something :)
00:30:09 <Eddi|zuHause> yeah, i'm not fond of porting to python3
00:33:43 <FLHerne> glx: cd scripts && sed -i 's/python/python2/' *.py
00:34:05 <FLHerne> (I had the same problem the other day)
00:34:14 <FLHerne> But fixing them would work too :p
00:39:03 <Eddi|zuHause> the problem is that there's things that were removed in python3 that are not a simple conversion
00:39:12 <Eddi|zuHause> like function parameter unpacking
00:43:59 <glx> ok the easiest fix is to modify python calls in makefile.in
00:44:13 <glx> but now I need to install libs for python2
00:45:58 <Eddi|zuHause> i have no clue which libs you need
00:46:13 <Eddi|zuHause> i used pixa for something, but i think that is optional
00:50:30 <glx> ah progress, I finally get a nml error
00:51:03 <glx> unexpected token comment, but I probably need to regenerate the caches
00:51:34 <Eddi|zuHause> yeah, you checked out the nml patch?
00:52:07 <glx> yes but need to compile a .nml with -R first
00:55:38 <glx> ok now I get the param error, finally :)
00:56:22 <Eddi|zuHause> nmlc -c --nfo src/headers.nfo src/headers.nml <-- this is the line from the makefile that threw the error for me
00:56:54 <glx> yes that's what gives me the error too
01:03:30 <glx> ok before any temp allocations I can see 40 reservations
01:05:49 <glx> 38 being from availability.gnml
01:07:27 <Eddi|zuHause> so it makes the "blah = " allocations globally, before the lines occur
01:08:05 <glx> 1 in railtype_definitions and 1 in recolour_maps
01:08:44 <Eddi|zuHause> recolour_maps is probably GRM
01:09:03 <Eddi|zuHause> that will always need storing in a parameter
01:12:20 <glx> yeah it seems all variables are stored globally, even if they are used only once
01:13:49 <glx> ha no they are used more than once
01:14:06 <Eddi|zuHause> i'm mildly worried that changing that would destroy my build process :)
01:15:12 <glx> hmm availability globals could be replaced by procedures
01:15:32 <Eddi|zuHause> yeah, those weren't available when i programmed this
01:16:15 <Eddi|zuHause> an even better candidate for procedures would be the capacity callbacks
01:16:52 <glx> to simplify switch chains ?
01:18:36 <Eddi|zuHause> i think most of them are duplicated for different numbers, which could be parameterized
01:19:12 <Eddi|zuHause> that, however, doesn't have anything to do with the actionD limit
01:19:49 <Eddi|zuHause> another thing that could be useful would be to try an attempt at sprite composition
01:22:17 *** ChanServ sets mode: +v tokai
01:32:05 <Eddi|zuHause> "Substring "STR_NAME_ENG_ROLLWAGEN" does not exist" wtf does this guy think i know how to translate this stuff?!?
01:35:38 <Eddi|zuHause> hm... i'm missing a dependency on langfiles somewhere
01:35:49 <glx> replaced 13 availability globals with procedures and headers.nml compiles
01:35:58 <glx> nmlc info: Concurrent ActionD registers: 64/64 (None)
01:37:05 <Eddi|zuHause> have a patch? i could use an example
01:37:45 <Eddi|zuHause> i'm more interested in the example than the patch :)
01:37:58 <glx> and I think I should check the nfo to be sure it does the right thing
01:38:33 <glx> switch(FEAT_TRAINS, SELF, avail_bav_1_core, (param_amount >= 1) && (param_epoch1 == 1 || param_epoch1 == 2 || param_epoch1 == 3)) { return; }
01:38:58 <glx> that's the first one, other are modified in a similar way
01:42:13 <Eddi|zuHause> nmlc ERROR: "src/DB_AG/DB_AG.gnml", line 28162: Syntax error, unexpected token ";" <-- what? uhm...
01:43:44 <Eddi|zuHause> ok, that's an error in the tracking table
01:45:01 <Eddi|zuHause> i should probably do some error checking for that
01:45:18 <glx> yes the string() line is weird
01:46:42 <Eddi|zuHause> yeah, someone put a ; where a , should go
01:47:07 <Eddi|zuHause> easy to miss in a table with 1000 lines :p
01:47:42 <Eddi|zuHause> name: string(STR_NAME_ENG_DB_AG_Stw_D_160,string(STR_NAME_ENG_DVT),string(STR_NAME_ENG_DOUBLE_DECK),string(STR_NAME_ENG_FAST)); <-- looks better now :)
01:49:32 <DorpsGek_III> [OpenTTD/OpenTTD] James103 commented on pull request #8156: Fix #8155: Roadtype speed limit in toolbar dropdown in scenario editor was doubled. https://git.io/Jfz4A
01:52:09 <glx> I'm trying to understand string() syntax, but I can't find it in the wiki
01:53:46 <Eddi|zuHause> it's not that complicated
01:54:07 <Eddi|zuHause> just string(<name>[,<param>]*)
01:55:50 <Eddi|zuHause> now... where did i put the cargo translation table? seems i'm missing something
01:56:58 <DorpsGek_III> [OpenTTD/OpenTTD] James103 commented on issue #8049: Suggestion: Allow Game Scripts to set the max loan of a company. https://git.io/Jv7Jj
02:02:47 *** tokai|noir has joined #openttd
02:02:47 *** ChanServ sets mode: +v tokai|noir
02:03:16 <Eddi|zuHause> ah, i think i found it
02:11:10 <Eddi|zuHause> "STR_NAME_ENG_KLEINLOK_LSTGRUPPE" wtf does that even mean in german?!?
02:13:59 <Eddi|zuHause> oh... LEISTUNGSGRUPPE
02:16:08 <Eddi|zuHause> i'm sorry, mr. Oberhümer, you get some vetos on this one...
02:22:59 <Eddi|zuHause> can't i get a list of all missing strings, instead of going through this one by one?
02:30:58 <glx> nmlc stops on first error
02:34:36 <Eddi|zuHause> turn it into a warning, and use the string name as string content?
02:39:04 <glx> I think there deps issues in the makefile, a modified gnml doesn't update the nml
02:42:09 <Eddi|zuHause> i noticed a few of those
02:43:21 <Eddi|zuHause> like, changing the lang/*.lng.in files doesn't regenerate lang/*.lng files, or changing the CTT doesn't regenerate the header files
02:52:47 *** ChanServ sets mode: +v tokai
03:46:30 *** tokai|noir has joined #openttd
03:46:30 *** ChanServ sets mode: +v tokai|noir
04:37:29 *** ChanServ sets mode: +v tokai
04:42:15 <glx> Eddi|zuHause: can't use procedure in availability.gnml, properties only work with actionD
04:44:12 <Eddi|zuHause> ok, so i won't try that then
04:45:21 <Eddi|zuHause> currently fighting my way through missing image files and whatever else Oberhümer has broken over the past few years
04:48:35 *** tokai|noir has joined #openttd
04:48:35 *** ChanServ sets mode: +v tokai|noir
05:14:29 <Eddi|zuHause> anything i can actually do to fix these? "libpng warning: iCCP: known incorrect sRGB profile"
05:14:56 <Eddi|zuHause> i'm getting like a million of those [not exaggerated]
05:16:19 <Eddi|zuHause> if i pause at the right moment i'm seeing a dozen "libpng warning: iCCP: cHRM chunk does not match sRGB" mixed in there
05:38:09 <glx> I have a possible solution for the issue, I'm trying to refcount all Identifiers, and discard assignment to never used variables
05:44:20 <Eddi|zuHause> i'm not sure how that helps me
05:44:50 <Eddi|zuHause> anyway, i've got a compiled grf, and i'm calling it a day
05:45:22 *** WormnestAndroid has quit IRC
05:45:23 <Eddi|zuHause> nobody else will get a compiled grf :)
05:45:28 <glx> it reduces global param usage
05:45:36 *** WormnestAndroid has joined #openttd
05:46:10 <glx> clean headers.nml compiles fine and nmlc info: Concurrent ActionD registers: 38/64 (None)
05:46:46 <glx> and using make I manage to compile until a missing png
05:47:51 <Eddi|zuHause> that's not going to work. the point of the headers file is to keep everything synchronized between the multiple partial compiles, so any variables you optimize out, i must force back in in the dummy code section
05:48:28 <Eddi|zuHause> so if the criterium to get them back is i have to reference them, i must add code that references them. which brings us back over the limit
05:51:11 <glx> onml includes the header too it seems
05:52:24 <Eddi|zuHause> but it must contain the exact same IDs for the global variables in every partial compile. none of the header stuff may be optimized out for not being used
05:52:51 <Eddi|zuHause> the dummy code is there to force at least one use
05:53:26 <Eddi|zuHause> so currently i compile multiple onml files of the form: <header><partial grf><dummy code>
05:54:31 <Eddi|zuHause> and stitch them together by cutting off <header> and <dummy code>, resulting in an onfo file of the form: <header><partial grf 1><partial grf 2>...<partial grf n>
05:55:02 <Eddi|zuHause> which in turn gets put through grfcodec
05:56:02 <Eddi|zuHause> optimizing out unused variables may help someone, but not me
05:56:05 <glx> I don't think it's an issue for availabilty globals
05:56:41 <glx> action6 will use the most recent value
05:57:06 <glx> but you may need to split/join your code differently
05:57:13 <Eddi|zuHause> yes, it is. they're parameter IDs, they must be the same for all partial IDs, no matter which subsection of them they actually use
05:57:45 <Eddi|zuHause> err... partial GRFs
05:58:20 <glx> but you never access them by paramID, only by identifier
05:58:43 <Eddi|zuHause> but i output to NFO, then they become paramIDs
05:59:07 <glx> I filter only xxx = blah; stuff
05:59:30 <glx> all other are assigned as before
05:59:51 <Eddi|zuHause> i'm not sure we're talking about the same thing
06:00:32 <glx> I'll push a branch for you to check
06:00:47 <glx> but not now, I really need to sleep :)
06:33:34 *** WormnestAndroid has quit IRC
06:34:50 *** WormnestAndroid has joined #openttd
06:40:05 *** WormnestAndroid has quit IRC
06:40:21 *** WormnestAndroid has joined #openttd
07:00:10 *** ChanServ sets mode: +v tokai
07:50:52 *** sla_ro|master has joined #openttd
08:35:46 *** andythenorth has joined #openttd
09:02:19 <LordAro> andythenorth: alternatively, RC1?
09:03:46 *** Maarten has joined #openttd
11:22:11 *** WormnestAndroid has quit IRC
11:22:24 *** WormnestAndroid has joined #openttd
11:35:45 *** WormnestAndroid has quit IRC
11:36:02 *** WormnestAndroid has joined #openttd
13:16:59 <DorpsGek_III> [OpenTTD/OpenTTD] michicc merged pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAk
13:18:56 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzFW
14:12:19 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzAJ
14:21:34 <andythenorth> note the rail line icon :)
14:25:42 *** plastic has joined #openttd
14:28:52 *** snail_UES_ has joined #openttd
14:31:34 *** gelignite has joined #openttd
15:04:29 *** supermop_Home_ has joined #openttd
15:07:25 <Eddi|zuHause> i'd assume that's a copy from sim city
15:08:47 <Eddi|zuHause> but why does that "screen shot" look like it's printed out and scanned back in by photographing the sheet of paper on the table?
15:13:48 <Eddi|zuHause> nmlc info: Concurrent ActionD registers: 77/96 (None) <-- very ... err... what?
15:15:16 <Eddi|zuHause> yes, but the "None" part
15:15:29 <FLHerne> That's supposed to be `str(free_parameters.stats[1])`
15:15:52 <Eddi|zuHause> that should be a (source-file, line#)
15:17:12 <FLHerne> Hm, I guess the position gets lost somewhere...
15:18:29 <Eddi|zuHause> i think that's because it's deep inside the RTT magic
15:18:51 <Eddi|zuHause> if i comment out the RTT, it shows an actual position
15:33:48 <Eddi|zuHause> now the real question is: a static approach (by which the parameter/actionD split is set via command line or something) or a dynamic approach (param and actionD can be popped until they collide)
15:40:13 <Eddi|zuHause> actually, why don't they draw from the same pool in the first place?
15:53:36 <DorpsGek_III> [OpenTTD/nml] Eddi-z opened pull request #149: Feature: Dynamically apply the limit for ActionD params https://git.io/Jfgef
15:54:41 <Eddi|zuHause> ok, regression disagrees with me :p
15:56:46 <Eddi|zuHause> need to catch the case where preprocessing grf params is never run in the first place
15:57:54 <Eddi|zuHause> when there's no grf-block
15:58:44 <glx> but grf-block is required I think
15:59:00 <Eddi|zuHause> apparently not in the regression tests
15:59:15 <Eddi|zuHause> at least in 002_sound
16:00:09 <glx> ah yes, regression tends to build non working grfs
16:01:05 <Eddi|zuHause> but, need to go shopping first
16:02:17 *** supermop_Home_ has quit IRC
16:06:30 <Speeder> locks slow down boats?
16:06:40 <Speeder> or their cost is only the expense building them?
16:07:22 <Eddi|zuHause> what do you mean "slow down"? they go in places that ships wouldn't be able to cross in the first place
16:07:40 <Eddi|zuHause> otherwise, i believe they go there same speed as in canals
16:08:14 <glx> there's a slow down waiting for the water level to egalise
16:09:48 <glx> but boats can't change level without them
16:13:32 <FLHerne> glx: I asked a while ago if it's correct that no-grf-block is allowed
16:13:46 <FLHerne> Eddi said forbidding it would break his use-case :p
16:15:09 <Eddi|zuHause> did i really say that?
16:15:20 <Eddi|zuHause> because i don't think it actually does
16:16:02 <glx> base grf don't use it IIRC
16:19:28 <Eddi|zuHause> FLHerne: i found the question in the logs, but i don't see any involvement of me in the following discussion
16:19:59 <FLHerne> I thought so, but my memory could be lying to me...
16:20:34 <FLHerne> I don't remember anyone else using partial nml files like that
16:21:17 <glx> Eddi|zuHause: as grf-block must be the first block, can't you just default to full range and reduce the range while parsing the block ?
16:21:18 <Eddi|zuHause> but all my partial compiles contain grf blocks, i just chop them off afterwards
16:22:45 <FLHerne> I'm sorry, you didn't, I must have hallucinated it
16:23:03 <FLHerne> (you're telling me the voices in my head aren't real?!)
16:23:27 <FLHerne> In that case, maybe just enforce that there be a grf block and see if anyone complains
16:23:46 <Eddi|zuHause> well... how am i going to argue with the regression test? :p
16:25:09 <FLHerne> Declare it to be wrong, and change it :p
16:25:27 <FLHerne> They're to avoid accidental regressions, not block deliberate ones
16:28:17 <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #149: Feature: Dynamically apply the limit for ActionD params https://git.io/Jfgef
16:30:51 <Eddi|zuHause> that seems to have worked
16:33:11 <Eddi|zuHause> glx: moving the assignments after __END_HEADERS__ was previously not viable, as it was meant to be one compile unit per vehicle, but currently it's clusterging a bunch of vehicles together so it might work
16:33:45 <Eddi|zuHause> glx: but the better question would be to ask why the assignments are already reserved during the RTT evaluation
16:35:13 <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #149: Feature: Dynamically apply the limit for ActionD params https://git.io/Jfgef
16:36:28 <Eddi|zuHause> so, i made an attempt at a comment, and un-WIP'd the PR
16:39:07 <Eddi|zuHause> (rebased that one on top of the other branch, to make cets compile)
16:40:54 <glx> because RTT gets temp parameter in get_action_list and that step comes after pre_processing
16:51:17 <glx> anyway I think your dynamic limit is not optimal as it still reserve all ids before the higher param, if you define param num to 0x80 in .nml you disable all internal calculation
16:52:37 *** supermop_Home has joined #openttd
16:54:51 <Eddi|zuHause> i'm not following your argument
16:57:25 <glx> during grf parameters reservation it starts at 0, then param.pre_process(expression.ConstantNumeric(param_num)) will use the auto value, unless there was a value in .nml, then the next index will be param num + 1
16:59:42 <Eddi|zuHause> yeah, i didn't touch any of that
17:00:03 <Eddi|zuHause> except for the upper limit, which is now the full range up to 0x80
17:00:25 <Eddi|zuHause> (excluding, i presume)
17:01:03 <Eddi|zuHause> (actually, these checks look wrong)
17:01:22 <glx> I think a better option would be to delegate param number reservation to free_number_list
17:01:48 <glx> something like pop_unique()
17:02:28 <FLHerne> Eddi|zuHause: > the better question would be to ask why the assignments are already reserved during the RTT evaluation
17:02:38 <FLHerne> It's in different passes
17:02:51 <FLHerne> Parameter assignments are reserved during register_names
17:03:50 <FLHerne> The RTT stuff is done later, in get_action_list
17:04:31 <Eddi|zuHause> glx: dunno if that is good, because the fixed param number in .nml might be useful for that weird param assignment statement that frosch linked
17:04:41 <FLHerne> glx: Er, isn't that already done? pop_global()
17:04:54 <FLHerne> Or do I misunderstand
17:05:11 <Eddi|zuHause> glx: so those skipped numbers would be free to use in user code, and never reserved by actionD
17:06:21 <supermop_Home> andythenorth i like playing steeltown for cute city games, as the industries all look good in towns
17:06:38 <supermop_Home> but invariably i get like a car assembly plant on top of a mountain
17:06:40 <Eddi|zuHause> glx: but i don't have a full picture of how that actually works
17:07:32 <Eddi|zuHause> supermop_Home: you need a landscape generator with pointier mountain tops and wider valleys
17:11:57 *** Wormnest has joined #openttd
17:12:13 <glx> FLHerne: pop_global() is never used it seems, and it looks like it just uses pop()
17:12:55 <FLHerne> glx: It's confusing, look at *what* it's calling pop() on
17:13:27 <FLHerne> It removes the number from free_number_list entirely
17:13:37 <FLHerne> I'm not convinced that's actually right
17:14:29 <glx> pop_unique() also remove number from the list
17:14:35 <andythenorth> supermop_Home that's the ideal place
17:15:05 <planetmaker> IIRC... the grf parameters double as global variables. So adding/removing might happen at other times, too
17:15:41 <Eddi|zuHause> no, the global variables fall into the ActionD section
17:16:06 <FLHerne> Hm, I don't think pop_global() does necessarily work as intended
17:16:33 <FLHerne> Because there *are* multiple passes
17:16:55 <Eddi|zuHause> i won't change anything until you actually reached a consensus on what things actually do that need changing :p
17:17:02 <FLHerne> So it ensures the param isn't re-allocated for the rest of the nmlc compile
17:17:15 <FLHerne> But it might have *already* been used later in the file
17:17:26 <glx> yes like pop_unique() without the uniqueness check
17:18:09 <FLHerne> Well, pop_unique() without any uniqueness check is just pop() :p
17:18:31 <FLHerne> pop_global() is supposed to be unique for the remainder of the output
17:20:18 <glx> hmm no, pop() can be reverted, pop_unique() cannot
17:22:12 <FLHerne> I think we're talking at cross purposes
17:27:07 <glx> hmm if pop_unique() is called between pop() and restore() the "unique" number can be reused by next pop() call
17:29:12 <glx> ah no it's ok, it was never used before
17:29:26 <glx> so my scenario can't happen
17:32:54 <glx> pop_global() really seems wrong, luckily it's not used
17:38:26 <glx> after more simulating in my head, I think pop_global() works as expected
17:45:45 *** Wormnest has joined #openttd
19:15:19 *** sla_ro|master has joined #openttd
19:34:07 *** Progman has joined #openttd
19:44:27 *** frosch123 has joined #openttd
19:45:52 <DorpsGek_III> - Update: Translations from eints (by translators)
19:58:53 <Eddi|zuHause> glx: that goes a bit deeper than i would go. also, you need a new ability in the grf block to add internal parameters
20:06:48 *** Gustavo6046 has joined #openttd
20:28:52 *** Gustavo6046 has joined #openttd
21:09:49 <supermop_Home> we have no meetings rest of the week due to germany being closed
21:26:02 *** kiwitree has joined #openttd
21:46:34 *** ChanServ sets mode: +o Yexo
22:59:48 <DorpsGek_III> [OpenTTD/OpenTTD] LubosKolouch commented on issue #8101: (Streetcar) vehicles do not use all open stations/gates https://git.io/JfmVJ
23:11:38 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on issue #8101: (Streetcar) vehicles do not use all open stations/gates https://git.io/JfmVJ
23:14:02 *** ChanServ sets mode: +v tokai
23:45:12 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #8101: (Streetcar) vehicles do not use all open stations/gates https://git.io/JfmVJ
continue to next day ⏵
