Config
Log for #openttd on 20th May 2020:
Times are UTC Toggle Colours
00:02:47  *** tokai|noir has joined #openttd
00:02:47  *** ChanServ sets mode: +v tokai|noir
00:03:16  <Eddi|zuHause> ah, i think i found it
00:09:49  *** tokai has quit IRC
00:11:10  <Eddi|zuHause> "STR_NAME_ENG_KLEINLOK_LSTGRUPPE" wtf does that even mean in german?!?
00:13:59  <Eddi|zuHause> oh... LEISTUNGSGRUPPE
00:16:08  <Eddi|zuHause> i'm sorry, mr. Oberhümer, you get some vetos on this one...
00:22:59  <Eddi|zuHause> can't i get a list of all missing strings, instead of going through this one by one?
00:30:58  <glx> nmlc stops on first error
00:34:36  <Eddi|zuHause> turn it into a warning, and use the string name as string content?
00:39:04  <glx> I think there deps issues in the makefile, a modified gnml doesn't update the nml
00:41:56  <Eddi|zuHause> yeah
00:42:09  <Eddi|zuHause> i noticed a few of those
00: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
00:52:47  *** tokai has joined #openttd
00:52:47  *** ChanServ sets mode: +v tokai
00:59:58  *** tokai|noir has quit IRC
01:46:30  *** tokai|noir has joined #openttd
01:46:30  *** ChanServ sets mode: +v tokai|noir
01:53:28  *** tokai has quit IRC
02:27:49  *** cHawk- has quit IRC
02:28:08  *** cHawk has joined #openttd
02:33:08  *** Flygon has joined #openttd
02:37:29  *** tokai has joined #openttd
02:37:29  *** ChanServ sets mode: +v tokai
02:42:15  <glx> Eddi|zuHause: can't use procedure in availability.gnml, properties only work with actionD
02:44:12  <Eddi|zuHause> ok, so i won't try that then
02:44:37  <glx> I tried :)
02:44:38  *** tokai|noir has quit IRC
02:45:21  <Eddi|zuHause> currently fighting my way through missing image files and whatever else Oberhümer has broken over the past few years
02:48:35  *** tokai|noir has joined #openttd
02:48:35  *** ChanServ sets mode: +v tokai|noir
02:55:28  *** tokai has quit IRC
02:58:29  *** D-HUND has joined #openttd
03:01:56  *** debdog has quit IRC
03:14:29  <Eddi|zuHause> anything i can actually do to fix these? "libpng warning: iCCP: known incorrect sRGB profile"
03:14:56  <Eddi|zuHause> i'm getting like a million of those [not exaggerated]
03: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
03: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
03:40:04  *** cHawk- has joined #openttd
03:44:20  <Eddi|zuHause> i'm not sure how that helps me
03:44:50  <Eddi|zuHause> anyway, i've got a compiled grf, and i'm calling it a day
03:45:22  *** WormnestAndroid has quit IRC
03:45:23  <Eddi|zuHause> nobody else will get a compiled grf :)
03:45:28  <glx> it reduces global param usage
03:45:36  *** WormnestAndroid has joined #openttd
03:46:08  *** cHawk has quit IRC
03:46:10  <glx> clean headers.nml compiles fine and nmlc info: Concurrent ActionD registers: 38/64 (None)
03:46:46  <glx> and using make I manage to compile until a missing png
03: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
03: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
03:51:11  <glx> onml includes the header too it seems
03:51:20  <Eddi|zuHause> yes
03:52:25  <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
03:52:51  <Eddi|zuHause> the dummy code is there to force at least one use
03:53:26  <Eddi|zuHause> so currently i compile multiple onml files of the form: <header><partial grf><dummy code>
03: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>
03:55:02  <Eddi|zuHause> which in turn gets put through grfcodec
03:56:02  <Eddi|zuHause> optimizing out unused variables may help someone, but not me
03:56:05  <glx> I don't think it's an issue for availabilty globals
03:56:41  <glx> action6 will use the most recent value
03:57:06  <glx> but you may need to split/join your code differently
03: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
03:57:45  <Eddi|zuHause> err... partial GRFs
03:58:20  <glx> but you never access them by paramID, only by identifier
03:58:43  <Eddi|zuHause> but i output to NFO, then they become paramIDs
03:59:07  <glx> I filter only xxx = blah; stuff
03:59:30  <glx> all other are assigned as before
03:59:51  <Eddi|zuHause> i'm not sure we're talking about the same thing
04:00:32  <glx> I'll push a branch for you to check
04:00:47  <glx> but not now, I really need to sleep :)
04:03:20  *** glx has quit IRC
04:33:34  *** WormnestAndroid has quit IRC
04:34:50  *** WormnestAndroid has joined #openttd
04:36:17  *** adikt has joined #openttd
04:40:05  *** WormnestAndroid has quit IRC
04:40:21  *** WormnestAndroid has joined #openttd
05:00:10  *** tokai has joined #openttd
05:00:10  *** ChanServ sets mode: +v tokai
05:07:09  *** tokai|noir has quit IRC
05:16:14  *** snail_UES_ has quit IRC
05:23:50  *** berndj has quit IRC
05:24:20  *** berndj has joined #openttd
05:44:07  *** berndj has quit IRC
05:50:52  *** sla_ro|master has joined #openttd
05:51:24  *** berndj has joined #openttd
06:35:46  *** andythenorth has joined #openttd
06:53:54  <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on pull request #8135: Prepare for 1.10.2 release https://git.io/JfzPC
07:02:19  <LordAro> andythenorth: alternatively, RC1?
07:02:59  *** Maarten has quit IRC
07:03:46  *** Maarten has joined #openttd
07:05:01  <andythenorth> also
07:06:11  *** cHawk- has quit IRC
07:08:52  *** keoz has joined #openttd
07:38:36  *** cHawk has joined #openttd
07:43:40  *** cHawk- has joined #openttd
07:43:40  *** cHawk has quit IRC
07:52:59  *** cHawk- has quit IRC
07:55:22  <andythenorth> https://obscuritory.com/sim/when-simcity-got-serious/
07:59:23  *** iSoSyS has joined #openttd
08:00:24  <andythenorth> I might rename FIRS chemical economy https://obscuritory.com/wp-content/uploads/2020/05/simrefinery.png
08:01:17  *** iSoSyS has quit IRC
08:38:36  *** cHawk has joined #openttd
09:22:11  *** WormnestAndroid has quit IRC
09:22:24  *** WormnestAndroid has joined #openttd
09:29:43  *** supermop_Home has quit IRC
09:35:45  *** WormnestAndroid has quit IRC
09:36:02  *** WormnestAndroid has joined #openttd
09:40:42  *** Samu has joined #openttd
10:35:06  *** nielsm has joined #openttd
11:10:35  <Samu> hi
11: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
11: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
11:53:38  *** iSoSyS has joined #openttd
11:57:51  *** cHawk has quit IRC
12:05:51  *** iSoSyS has quit IRC
12: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
12:21:14  <andythenorth> https://obscuritory.com/wp-content/uploads/2020/05/simrefinery_10.png
12:21:34  <andythenorth> note the rail line icon :)
12:23:09  *** heffer has quit IRC
12:25:42  *** plastic has joined #openttd
12:28:52  *** snail_UES_ has joined #openttd
12:30:51  *** plstc has quit IRC
12:31:34  *** gelignite has joined #openttd
12:48:30  *** glx has joined #openttd
12:48:30  *** ChanServ sets mode: +v glx
13:04:30  *** supermop_Home_ has joined #openttd
13:07:26  <Eddi|zuHause> i'd assume that's a copy from sim city
13: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?
13:13:48  <Eddi|zuHause>  nmlc info: Concurrent ActionD registers: 77/96 (None) <-- very ... err... what?
13:14:23  <FLHerne> 77/96 sounds good
13:15:17  <Eddi|zuHause> yes, but the "None" part
13:15:29  <FLHerne> That's supposed to be `str(free_parameters.stats[1])`
13:15:52  <Eddi|zuHause> that should be a (source-file, line#)
13:17:12  <FLHerne> Hm, I guess the position gets lost somewhere...
13:18:29  <Eddi|zuHause> i think that's because it's deep inside the RTT magic
13:18:51  <Eddi|zuHause> if i comment out the RTT, it shows an actual position
13:26:56  *** keoz has quit IRC
13: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)
13:40:13  <Eddi|zuHause> actually, why don't they draw from the same pool in the first place?
13:49:18  <glx> Eddi|zuHause: https://github.com/OpenTTD/nml/compare/master...glx22:identifiers and I think it should work in your workflow if you move availability.gnml block after __END_HEADERS__ comment
13:53:36  <DorpsGek_III> [OpenTTD/nml] Eddi-z opened pull request #149: Feature: Dynamically apply the limit for ActionD params https://git.io/Jfgef
13:54:41  <Eddi|zuHause> ok, regression disagrees with me :p
13:56:46  <Eddi|zuHause> need to catch the case where preprocessing grf params is never run in the first place
13:57:54  <Eddi|zuHause> when there's no grf-block
13:58:44  <glx> but grf-block is required I think
13:59:00  <Eddi|zuHause> apparently not in the regression tests
13:59:15  <Eddi|zuHause> at least in 002_sound
14:00:09  <glx> ah yes, regression tends to build non working grfs
14:01:05  <Eddi|zuHause> but, need to go shopping first
14:02:17  *** supermop_Home_ has quit IRC
14:06:30  <Speeder> locks slow down boats?
14:06:40  <Speeder> or their cost is only the expense building them?
14: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
14:07:40  <Eddi|zuHause> otherwise, i believe they go there same speed as in canals
14:08:14  <glx> there's a slow down waiting for the water level to egalise
14:08:28  <glx> like a real lock
14:09:48  <glx> but boats can't change level without them
14:13:32  <FLHerne> glx: I asked a while ago if it's correct that no-grf-block is allowed
14:13:46  <FLHerne> Eddi said forbidding it would break his use-case :p
14:15:09  <Eddi|zuHause> did i really say that?
14:15:20  <Eddi|zuHause> because i don't think it actually does
14:16:03  <glx> base grf don't use it IIRC
14:18:09  <glx> except extra
14: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
14:20:00  <FLHerne> I thought so, but my memory could be lying to me...
14:20:34  <FLHerne> I don't remember anyone else using partial nml files like that
14:20:43  * FLHerne goes log-grepping
14: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 ?
14:21:18  <Eddi|zuHause> but all my partial compiles contain grf blocks, i just chop them off afterwards
14:22:46  <FLHerne> I'm sorry, you didn't, I must have hallucinated it
14:23:03  <FLHerne> (you're telling me the voices in my head aren't real?!)
14:23:27  <FLHerne> In that case, maybe just enforce that there be a grf block and see if anyone complains
14:23:46  <Eddi|zuHause> well... how am i going to argue with the regression test? :p
14:25:09  <FLHerne> Declare it to be wrong, and change it :p
14:25:27  <FLHerne> They're to avoid accidental regressions, not block deliberate ones
14:25:29  <glx> well for now it crashes
14:28:17  <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #149: Feature: Dynamically apply the limit for ActionD params https://git.io/Jfgef
14:30:51  <Eddi|zuHause> that seems to have worked
14:32:26  *** keoz has joined #openttd
14: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
14:33:45  <Eddi|zuHause> glx: but the better question would be to ask why the assignments are already reserved during the RTT evaluation
14:35:13  <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #149: Feature: Dynamically apply the limit for ActionD params https://git.io/Jfgef
14:36:28  <Eddi|zuHause> so, i made an attempt at a comment, and un-WIP'd the PR
14:38:24  <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #21: Eddi-nml branch for ActionC support https://git.io/fhpED
14:39:07  <Eddi|zuHause> (rebased that one on top of the other branch, to make cets compile)
14:40:54  <glx> because RTT gets temp parameter in get_action_list and that step comes after pre_processing
14:48:13  *** Gustavo6046 has quit IRC
14:49:00  *** sla_ro|master has quit IRC
14: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
14:52:37  *** supermop_Home has joined #openttd
14:54:09  <Eddi|zuHause> huh?
14:54:51  <Eddi|zuHause> i'm not following your argument
14: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
14:59:42  <Eddi|zuHause> yeah, i didn't touch any of that
14:59:52  <glx> I know :)
15:00:03  <Eddi|zuHause> except for the upper limit, which is now the full range up to 0x80
15:00:25  <Eddi|zuHause> (excluding, i presume)
15:01:03  <Eddi|zuHause> (actually, these checks look wrong)
15:01:22  <glx> I think a better option would be to delegate param number reservation to free_number_list
15:01:48  <glx> something like pop_unique()
15:02:28  <FLHerne> Eddi|zuHause: > the better question would be to ask why the assignments are already reserved during the RTT evaluation
15:02:38  <FLHerne> It's in different passes
15:02:51  <FLHerne> Parameter assignments are reserved during register_names
15:03:50  <FLHerne> The RTT stuff is done later, in get_action_list
15: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
15:04:41  <FLHerne> glx: Er, isn't that already done? pop_global()
15:04:54  <FLHerne> Or do I misunderstand
15:05:11  <Eddi|zuHause> glx: so those skipped numbers would be free to use in user code, and never reserved by actionD
15:06:21  <supermop_Home> andythenorth i like playing steeltown for cute city games, as the industries all look good in towns
15:06:38  <supermop_Home> but invariably i get like a car assembly plant on top of a mountain
15:06:40  <Eddi|zuHause> glx: but i don't have a full picture of how that actually works
15:07:32  <Eddi|zuHause> supermop_Home: you need a landscape generator with pointier mountain tops and wider valleys
15:11:57  *** Wormnest has joined #openttd
15:12:13  <glx> FLHerne: pop_global() is never used it seems, and it looks like it just uses pop()
15:12:55  <FLHerne> glx: It's confusing, look at *what* it's calling pop() on
15:13:26  <glx> ha right
15:13:27  <FLHerne> It removes the number from free_number_list entirely
15:13:37  <FLHerne> I'm not convinced that's actually right
15:14:29  <FLHerne> Now I am
15:14:29  <glx> pop_unique() also remove number from the list
15:14:35  <andythenorth> supermop_Home that's the ideal place
15:15:05  <planetmaker> IIRC... the grf parameters double as global variables. So adding/removing might happen at other times, too
15:15:41  <Eddi|zuHause> no, the global variables fall into the ActionD section
15:15:55  <glx> like grf parameters ;)
15:16:04  <glx> same memory area
15:16:06  <FLHerne> Hm, I don't think pop_global() does necessarily work as intended
15:16:33  <FLHerne> Because there *are* multiple passes
15:16:55  <Eddi|zuHause> i won't change anything until you actually reached a consensus on what things actually do that need changing :p
15:17:02  <FLHerne> So it ensures the param isn't re-allocated for the rest of the nmlc compile
15:17:15  <FLHerne> But it might have *already* been used later in the file
15:17:26  <glx> yes like pop_unique() without the uniqueness check
15:18:09  <FLHerne> Well, pop_unique() without any uniqueness check is just pop() :p
15:18:31  <FLHerne> pop_global() is supposed to be unique for the remainder of the output
15:20:18  <glx> hmm no, pop() can be reverted, pop_unique() cannot
15:22:12  <FLHerne> I think we're talking at cross purposes
15:27:07  <glx> hmm if pop_unique() is called between pop() and restore() the "unique" number can be reused by next pop() call
15:29:12  <glx> ah no it's ok, it was never used before
15:29:26  <glx> so my scenario can't happen
15:32:54  <glx> pop_global() really seems wrong, luckily it's not used
15:38:26  <glx> after more simulating in my head, I think pop_global() works as expected
15:45:20  *** Wormnest has quit IRC
15:45:45  *** Wormnest has joined #openttd
16:01:38  *** gnu_jj has quit IRC
16:01:49  *** gnu_jj has joined #openttd
16:17:05  *** iSoSyS has joined #openttd
16:17:22  *** Flygon has quit IRC
16:51:42  *** Wolf01 has joined #openttd
17:15:19  *** sla_ro|master has joined #openttd
17:15:39  <glx> Eddi|zuHause: https://github.com/OpenTTD/nml/compare/master...glx22:dynamic-param something like maybe
17:34:08  *** Progman has joined #openttd
17:44:27  *** frosch123 has joined #openttd
17:44:40  *** iSoSyS has quit IRC
17:45:52  <DorpsGek_III> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/Jfgmb
17:45:52  <DorpsGek_III>   - Update: Translations from eints (by translators)
17:49:42  *** heffer has joined #openttd
17: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
18:06:48  *** Gustavo6046 has joined #openttd
18:13:44  *** keoz has quit IRC
18:28:34  *** Gustavo6046 has quit IRC
18:28:52  *** Gustavo6046 has joined #openttd
18:31:41  <andythenorth> yo
18:32:34  <frosch123> is it weekend?
18:32:43  <andythenorth> not yet
18:33:05  <Eddi|zuHause> it is here
18:40:13  <TrueBrain> same :D
18:57:31  *** cHawk has joined #openttd
19:09:50  <supermop_Home> we have no meetings rest of the week due to germany being closed
19:19:41  *** Progman has quit IRC
19:26:02  *** kiwitree has joined #openttd
19:28:31  *** cHawk- has joined #openttd
19:34:38  *** cHawk has quit IRC
19:43:04  *** cHawk- has quit IRC
19:46:34  *** Yexo has joined #openttd
19:46:34  *** ChanServ sets mode: +o Yexo
20:26:39  *** Yexo has quit IRC
20:59:48  <DorpsGek_III> [OpenTTD/OpenTTD] LubosKolouch commented on issue #8101: (Streetcar) vehicles do not use all open stations/gates https://git.io/JfmVJ
21:01:34  *** tokai has quit IRC
21:09:33  *** Wolf01 has quit IRC
21:11:38  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on issue #8101: (Streetcar) vehicles do not use all open stations/gates https://git.io/JfmVJ
21:14:02  *** tokai has joined #openttd
21:14:02  *** ChanServ sets mode: +v tokai
21:30:18  *** cHawk has joined #openttd
21:32:04  *** cHawk has quit IRC
21:33:15  *** cHawk has joined #openttd
21:35:54  *** kiwitree has quit IRC
21:37:04  *** cHawk has quit IRC
21:38:01  *** cHawk has joined #openttd
21:41:33  *** cHawk has quit IRC
21:43:04  *** cHawk has joined #openttd
21:43:26  *** Samu has quit IRC
21:45:12  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #8101: (Streetcar) vehicles do not use all open stations/gates https://git.io/JfmVJ
21:52:58  *** andythenorth has quit IRC
21:56:46  *** frosch123 has quit IRC
22:08:56  *** Progman has joined #openttd
22:21:33  *** Progman has quit IRC
22:24:53  *** sla_ro|master has quit IRC
22:27:34  *** cHawk- has joined #openttd
22:33:36  *** cHawk has quit IRC
22:41:33  <supermop_Home> if i need to deliver food to a town per GS
22:41:54  <supermop_Home> and it gets delivered to an industry that accepts food (like a store)
22:43:33  <supermop_Home> is  the town that gets the food based on the name of the industry ("Town A Grocery Store" vs "City B Grocery Store"), or the name of the station it is dropped off at?
22:44:12  <supermop_Home> "Town A Central" vs "City B Sidings"?
22:45:25  <supermop_Home> because i just spent $$$ building a port in this city and the industry is "Village X Port" instead of "City Y Port" :(
22:45:31  <FLHerne> supermop_Home: My guess would be the station
22:45:39  <glx> I think it depends on town's coverage area, but it's not the station
22:45:59  <glx> it's the tile receiving the cargo
22:46:01  *** Smedles has quit IRC
22:46:02  <FLHerne> Try it, in the name of science
22:46:58  <glx> (at least subsidies work that way, don't really know about GS)
22:47:18  *** Smedles has joined #openttd
22:47:38  <_dp_> depends on gs, usually it goes to the town of station
22:49:03  <_dp_> at least simple cb and aphid's cb work that way iirc
23:26:36  <supermop_Home> not sure yet, as the city is still a few people short of requiring food, so the town window doesn't yet show how much food it received last month
23:31:06  *** gelignite has quit IRC
23:32:25  *** gelignite has joined #openttd
23:34:16  <Eddi|zuHause> i'm fairly convinced it's the name of the station
23:39:39  <_dp_> Eddi|zuHause, strictly speaking it's not the name, they're just named after a town by default
23:40:17  <_dp_> but renaming station won't change anything
23:40:40  <Eddi|zuHause> yes, i know that, i just omitted that detail
23:53:31  *** gelignite has quit IRC

Powered by YARRSTE version: svn-trunk