Log for #openttd on 18th December 2019:
Times are UTC Toggle Colours
00:01:37  *** frosch has quit IRC
00:17:35  *** supermop_work has quit IRC
00:18:01  *** supermop_work has joined #openttd
00:48:16  *** supermop_work has quit IRC
00:50:20  *** supermop_work has joined #openttd
00:52:15  *** tokai|noir has joined #openttd
00:52:15  *** ChanServ sets mode: +v tokai|noir
00:59:03  *** tokai has quit IRC
01:20:35  *** supermop_work has quit IRC
01:36:31  *** supermop_work has joined #openttd
01:56:12  *** Progman has quit IRC
02:01:24  *** snail_UES_ has joined #openttd
02:06:46  *** supermop_work has quit IRC
02:08:12  *** supermop_work has joined #openttd
02:38:26  *** supermop_work has quit IRC
03:20:12  *** D-HUND has joined #openttd
03:23:37  *** debdog has quit IRC
03:32:21  *** Wormnest_ has quit IRC
03:59:25  *** glx has quit IRC
04:09:18  *** HerzogDeXtEr has quit IRC
05:41:06  *** tokai has joined #openttd
05:41:06  *** ChanServ sets mode: +v tokai
05:48:06  *** tokai|noir has quit IRC
06:13:01  *** snail_UES_ has quit IRC
06:22:08  *** sla_ro|master has joined #openttd
07:25:40  *** andythenorth has joined #openttd
08:06:40  *** D-HUND is now known as debdog
08:15:29  *** tokai|noir has joined #openttd
08:15:29  *** ChanServ sets mode: +v tokai|noir
08:22:33  *** tokai has quit IRC
08:32:51  *** andythenorth has quit IRC
08:41:57  <DorpsGek_III_> [OpenTTD/OpenTTD] LordAro commented on pull request #7863: Various tracktype related fixes
08:58:45  *** lugo has joined #openttd
08:59:28  *** andythenorth has joined #openttd
09:08:28  *** WormnestAndroid has quit IRC
09:08:41  *** WormnestAndroid has joined #openttd
09:28:42  *** Pikka has joined #openttd
09:32:15  *** andythenorth has quit IRC
09:46:00  *** Progman has joined #openttd
12:05:58  <FLHerne> In an nml switch, "return; returns the computed value directly as a callback result."
12:06:56  <FLHerne> 'the computed value' should be the result of the expression, same as is compared with the ranges?
12:11:39  <NGC3982_> is openttd stuff still written in nml?
12:11:43  *** NGC3982_ is now known as NGC3982
12:12:11  <FLHerne> Well, there's still m4nfo
12:12:15  <FLHerne> But mostly yes
12:13:04  <FLHerne> I'm confused because the expression does `foo % 50`
12:13:34  <FLHerne> So I'd expect the callback result when using just `return` to be in the range 0-50, but it isn't :P
12:13:46  <FLHerne> Or not always, anyway
12:14:40  <FLHerne> 0-49, even
12:17:11  *** HerzogDeXtEr has joined #openttd
12:18:41  <Eddi|zuHause> FLHerne: needs more context
12:21:26  <FLHerne> Eddi|zuHause: So, FIRS has these ridiculous switches
12:21:35  <FLHerne> switch(FEAT_INDUSTRYTILES, SELF, slag_grinding_plant_tile_2_anim_control, (extra_callback_info1 % 56)) {
12:21:41  <FLHerne> 0: return 0;
12:21:49  <FLHerne> 1: return 1;
12:22:04  <FLHerne> ...  55: return 55;
12:22:15  <Eddi|zuHause> yeah, that's no good...
12:22:38  <FLHerne> The way I read "return; returns the computed value directly as a callback result."
12:22:53  <Eddi|zuHause> yeah, have you checked the resulting NFO?
12:23:00  <FLHerne> it should be possible to replace that by `0..55: return;`, or even just `default: return;`
12:23:07  <FLHerne> But then it stops working :P
12:23:22  <FLHerne> And when I look at the vars in-game, they're being set to values that are way out of range
12:24:07  <Eddi|zuHause> you can run nmlc --nfo ... to generate nfo instead of grf
12:26:38  <FLHerne> switch(FEAT_INDUSTRYTILES, SELF, glass_works_tile_1_anim_control, (extra_callback_info1 % 71)) {
12:26:51  <FLHerne>     default: return;
12:26:52  <FLHerne> }
12:26:54  <FLHerne> generates
12:27:31  <FLHerne> // Name: glass_works_tile_1_anim_control
12:27:32  <FLHerne> 15220 * 21 02 09 E8 89
12:27:34  <FLHerne> 10 80 \dxFFFFFFFF \dx00000000 \dx00000047
12:27:35  <FLHerne> \b0
12:27:37  <FLHerne> \wx8000 // Return computed value
12:27:50  * FLHerne tries to parse that :P
12:30:40  <Eddi|zuHause> Action 02 Feature 09 ID E8 Type 89 (dword)
12:32:37  <Eddi|zuHause> var 10 [varadjust] shift 80 [shift-and-add-modulo] mask \dxFFFFFFFF add-val \dx00000000 modulo-val \dx00000047
12:33:11  <Eddi|zuHause> nvar \b0
12:33:15  <Eddi|zuHause> default \wx8000
12:33:22  <FLHerne> Odd, 89 doesn't seem right
12:33:42  <Eddi|zuHause> why?
12:35:05  *** Progman has quit IRC
12:35:52  <Eddi|zuHause> on first glance, i see nothing wrong with this nfo
12:39:26  *** andythenorth has joined #openttd
12:40:18  <FLHerne> No, I think that was based on reading the wrong table
12:40:40  <FLHerne> Now I just can't find what "89" is supposed to refer to at all :P
12:43:36  <Eddi|zuHause>
12:43:51  <Eddi|zuHause> "Access general variable or
12:43:53  <Eddi|zuHause> variable of the primary object"
12:44:03  <FLHerne> Ah
12:44:04  <Eddi|zuHause> 81/85/89
12:45:27  <Eddi|zuHause> var 10 being "general variable"
12:46:12  <Eddi|zuHause> as in
12:47:47  <FLHerne> So it reads var10, which is indeed extra_callback_info1, and does the modulo with the right value
12:48:55  <FLHerne> I can't find any equivalent in the NFO docs of what it says in the NML spec about that
12:48:57  <FLHerne>
12:49:22  <FLHerne> `anim_control ... extra_callback_info1: 32 random bits, if enabled in the special_flags property`
12:49:34  <FLHerne> So does NML set that somewhere?
12:49:50  <Eddi|zuHause> it'll be in here somewhere
12:50:29  <Eddi|zuHause> special flags would be in properties somewhere?
12:51:00  <FLHerne> Right, was looking at that page/section and still missed it...
12:51:08  <FLHerne> > Since TTDPatch 2.5 beta 2, these callbacks get random bits in variable 10, to allow randomizing changes.
12:51:22  <FLHerne> Which doesn't say anything about having to set a flag, but meh
12:52:52  <Eddi|zuHause> "From TTDPatch 2.5 beta 2, you can ask for random bits in variable 10. To enable this, set bit 3 of property 19 for houses, bit 0 of property 12 for industry tiles, bit 2 of property 13 for stations, or bit 12 of property 10 for objects."
12:54:15  <Eddi|zuHause> it's in the "next animation frame" callback, but not in the "animation control" callback
12:55:09  <FLHerne> Hm, I see
12:55:45  <Eddi|zuHause> dunno if that was intended, but if in doubt, the spec wins
12:55:53  <FLHerne> The nml docs explicitly have that against `anim_control`, so either it's being overcautious or the NFO spec is missing a bit
12:56:12  <FLHerne> Anyway, the flag is set, so it's kind of moot
12:56:17  <Eddi|zuHause> possibly the person writing the NML spec missed the difference
12:56:21  <FLHerne> Then nvar is 0, which is fine
12:57:01  *** SpComb has quit IRC
12:57:48  *** andythenorth has quit IRC
12:58:32  <FLHerne> So why is the default setid \wx8000
12:58:55  *** andythenorth has joined #openttd
12:59:51  <FLHerne> \wx80__ means it's a callback result?
12:59:57  <FLHerne> which it should be
13:00:23  <Eddi|zuHause> that's just a default value of 0 in case anything goes wrong elsewhere
13:01:06  <Eddi|zuHause> (maybe would be better to have this as "callback failed"?)
13:01:29  <Eddi|zuHause> shouldn't be relevant
13:02:06  <FLHerne> Ok, so > Since TTDPatch 2.0.1 alpha 57, nvar=0 is a special case. Instead of using ranges, nvar=0 means that the result of an advanced calculation (or, if no calculation is performed, the adjusted variable value itself) is returned as callback result, with bit 15 set.
13:02:16  <FLHerne> is the relevant part?
13:03:06  <FLHerne> i.e. it really /should/ return var10 % 71 as the callback result, like it's supposed to, which is what you said to begin with :P
13:03:59  <FLHerne> In which case how the heck is the animation frame getting set to weird values like 0xe1
13:05:04  <FLHerne> Is there any way to print/show values from inside a callback chain?
13:07:02  *** Samu has joined #openttd
13:07:50  <Eddi|zuHause> only with crazy high grf debug values, which is very spammy
13:08:26  <FLHerne> How crazy-high? I tried 9 and that didn't seem to show anything after init
13:08:34  <Eddi|zuHause> you could add debug output to src/newgrf_animation_base.h which is how far i currently got digging through the source
13:08:42  <FLHerne> (and map creation)
13:15:03  <Eddi|zuHause> brb (i hope)
13:15:19  *** Eddi|zuHause has quit IRC
13:20:39  *** Flygon has quit IRC
13:31:53  <DorpsGek_III_> [OpenTTD/website] auge8472 commented on pull request #113: Change: semantic HTML-elements for the pages main sections
13:48:53  <DorpsGek_III_> [OpenTTD/website] LordAro commented on pull request #113: Change: semantic HTML-elements for the pages main sections
13:50:58  *** snail_UES_ has joined #openttd
13:59:36  <DorpsGek_III_> [OpenTTD/OpenTTD] glx22 opened pull request #7864: Codechange: Replace FOR_ALL_XXX with range-based for loops
14:00:19  <LordAro> ooh
14:09:26  <DorpsGek_III_> [OpenTTD/OpenTTD] LordAro commented on pull request #7864: Codechange: Replace FOR_ALL_XXX with range-based for loops
14:10:17  <DorpsGek_III_> [OpenTTD/OpenTTD] glx22 updated pull request #7864: Codechange: Replace FOR_ALL_XXX with range-based for loops
14:10:44  <peter1138> 500 kcal lunch is not excessive is it?
14:18:44  *** snail_UES_ has quit IRC
14:20:55  *** snail_UES_ has joined #openttd
14:23:45  *** Eddi|zuHause has joined #openttd
14:26:36  <DorpsGek_III_> [OpenTTD/website] auge8472 dismissed a review for pull request #113: Change: semantic HTML-elements for the pages main sections
14:26:36  <DorpsGek_III_> [OpenTTD/website] auge8472 updated pull request #113: Change: semantic HTML-elements for the pages main sections
14:27:28  <Eddi|zuHause> hm, something's not right
14:31:37  <peter1138> With?
14:32:45  <Eddi|zuHause> my raid
14:33:39  <DorpsGek_III_> [OpenTTD/website] auge8472 commented on pull request #113: Change: semantic HTML-elements for the pages main sections
14:45:14  *** nielsm has joined #openttd
14:47:28  <peter1138> Oh
14:49:51  <DorpsGek_III_> [OpenTTD/website] LordAro approved pull request #113: Change: semantic HTML-elements for the pages main sections
14:49:51  *** supermop_work has joined #openttd
15:04:51  <DorpsGek_III_> [OpenTTD/website] auge8472 commented on pull request #113: Change: semantic HTML-elements for the pages main sections
15:05:38  *** WormnestAndroid has quit IRC
15:24:49  <DorpsGek_III_> [OpenTTD/website] TrueBrain commented on pull request #113: Change: semantic HTML-elements for the pages main sections
15:26:42  *** WormnestAndroid has joined #openttd
15:32:53  *** sla_ro|master has quit IRC
15:34:45  *** sla_ro|master has joined #openttd
15:35:08  *** Progman has joined #openttd
15:40:12  *** andythenorth has joined #openttd
15:50:02  *** Wormnest_ has joined #openttd
15:51:43  *** andythenorth has quit IRC
15:54:19  *** lugo has quit IRC
15:58:36  *** frosch123 has joined #openttd
16:04:23  <nielsm> I've been thinking, if we were to add pcm music playback to ottd, what would be the way to go. depend on ffmpeg and play virtually anything? just link in ogg/vorbis and flac libraries? what to ship on mac and windows?
16:05:21  <DorpsGek_III_> [OpenTTD/OpenTTD] glx22 commented on pull request #7864: Codechange: Replace FOR_ALL_XXX with range-based for loops
16:05:28  <nielsm> also I have looked around and it seems there is no such thing as a stand-alone mp3 decoder library
16:05:54  <nielsm> (that is recent and mature)
16:05:59  *** WormnestAndroid has quit IRC
16:09:04  <LordAro> yup
16:09:17  <LordAro> mostly due to fear of mp3 patents, which only recently expired
16:11:16  <frosch123> LordAro: did you find any usage of the filter predicate in glx' pr? or am i blind?
16:12:08  <LordAro> frosch123: the IterateType function in engine_base.h
16:15:28  *** glx has joined #openttd
16:15:29  *** ChanServ sets mode: +v glx
16:16:37  <frosch123> ah, thanks :)
16:16:56  <frosch123> i saw that stations and vehicles get away with IsValidID, but i did not think of engines
16:17:27  <glx> engines used a custom filter
16:18:21  <milek7_> nielsm: libmpg123
16:18:35  <glx> frosch123: it's also used for admin sockets
16:19:36  <milek7_> as for general sound playing, maybe libsndfile?
16:20:13  <milek7_> ffmpeg (libavformat+libavcodec) api is rather complicated..
16:20:23  <frosch123> nielsm: there are two ancient patches from orudge. no idea how useful :)
16:22:52  <nielsm> milek7_ yeah right after writing that line I recalled mpg123 existing
16:24:49  <nielsm> frosch123: the sound mixer thing is not as relevant as I already added music streaming to the mixer a while ago (for use with fluidsynth first), and I'm not sure if a patch against r3317 is much use on today's source tree ;)
16:25:28  *** WormnestAndroid has joined #openttd
16:25:56  <DorpsGek_III_> [OpenTTD/OpenTTD] glx22 commented on pull request #7864: Codechange: Replace FOR_ALL_XXX with range-based for loops
17:08:26  *** tokai has joined #openttd
17:08:26  *** ChanServ sets mode: +v tokai
17:08:50  <planetmaker> hm, do I read mp3 support in the pipe? :)
17:09:31  <frosch123> you can use an external player if you need it now :p
17:10:41  <nielsm> I've been thinking about how to design a better music system for a long time :P
17:13:39  <nielsm> changing the obm file format entirely would be the first step though
17:15:18  *** tokai|noir has quit IRC
17:19:33  *** supermop_work has quit IRC
17:22:01  <DorpsGek_III_> [OpenTTD/OpenTTD] glx22 updated pull request #7864: Codechange: Replace FOR_ALL_XXX with range-based for loops
17:26:55  *** WormnestAndroid has quit IRC
17:27:08  *** WormnestAndroid has joined #openttd
17:54:04  *** supermop_work has joined #openttd
18:01:11  *** andythenorth has joined #openttd
18:01:13  <andythenorth> lunch discipline has collapsed
18:02:34  *** andythenorth has quit IRC
18:03:52  <frosch123> was that a "help"?
18:18:38  *** andythenorth has joined #openttd
18:20:14  <andythenorth> FLHerne: thanks
18:20:23  <andythenorth> that was a copy-paste from stack overflow :oops
18:24:20  <FLHerne> Huh, usually SO is pretty good
18:24:24  <DorpsGek_III_> [OpenTTD/nml] glx22 commented on pull request #66: Add: allow use of switches and random switches as procedures
18:24:51  * FLHerne currently suffering from recursive madness
18:25:19  <Eddi|zuHause> you can only understand recursive madness if you understand recursive madness
18:27:00  <Eddi|zuHause> (but what exactly are we talking about?)
18:38:23  * andythenorth uses more procedures
18:41:08  *** Wolf01 has joined #openttd
18:45:46  <DorpsGek_III_> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
18:45:46  <DorpsGek_III_>   - Update: Translations from eints (by translators)
19:08:44  *** Progman_ has joined #openttd
19:14:06  *** Progman has quit IRC
19:14:17  *** Progman_ is now known as Progman
19:17:44  <Eddi|zuHause> "Rebuild Status : 62% complete" <- is it normal that this is taking this long?
19:18:13  <Eddi|zuHause> it's been almost 3 hours now?
20:20:55  <andythenorth> glx: what else needs tested before procedures are merged? :)
20:21:08  <andythenorth> we won't find any real issues until it's more widely used
20:21:24  <frosch123> did you find a usecase in horse?
20:21:29  <glx> yeah it needs real world testing now
20:22:03  <andythenorth> frosch123: there are some use cases that could also be done with global + registers
20:22:12  <andythenorth> but procedures seem to be marginally faster to compile
20:22:48  <frosch123> how much faster compared to old code?
20:23:43  <andythenorth> (from memory) with procedures: total 38-43s; with global switch + registers: 45-48s
20:24:10  <andythenorth> the difference could be local system load, but procedures are consistently faster than global + register
20:24:24  <andythenorth>
20:24:39  <frosch123> yeah, but compared to before you started optimising?
20:24:59  * andythenorth back in a couple of minutes...
20:25:19  <andythenorth> the relevant commit is
20:25:29  <andythenorth> and then there's a branch linked in the PR above
20:28:36  * andythenorth wonders if it was faster with the switches per vehicle :P
20:29:44  <andythenorth> a handful of local tests are rarely reliable, unless the differences are large
20:31:16  <andythenorth> also I have grfcodec in the final step :P
20:31:29  <andythenorth> but the nml times are reported, and are fairly consistent
20:32:50  *** syr has joined #openttd
20:35:05  <andythenorth> frosch123: no significant difference between procedures and global + registers in the nmlc step
20:35:29  <andythenorth> both are faster than stack of switches for every vehicle, but not by much in this specific case
20:35:57  <andythenorth> this is all using pypy for nmlc mind, and pypy is so much faster
20:37:07  <frosch123> ok, so all pypy :)
20:38:39  <andythenorth> pypy parses iron-horse.nml in 25% of the time that py38 takes
20:39:29  <andythenorth> ~4s vs ~16s
20:40:11  <andythenorth> preprocessing ~4s vs ~12s
20:40:23  <andythenorth> output is *much* slower under pypy than py38 though
20:40:32  <andythenorth> ~10s vs ~2s
20:40:45  <andythenorth> so py38 is 20% of the time for pypy on that step
20:41:43  <andythenorth> oof
20:42:00  * andythenorth considers having nmlc fork out to a different python for that step
20:42:05  <andythenorth> wonder what the overhead would be :P
20:42:40  <andythenorth> probably tragic :D
20:44:19  * andythenorth should read about what a JIT even is :P
20:45:27  <glx> JIT is just in time
20:46:08  <andythenorth> I know that much :)
20:46:28  <andythenorth> I'm curious why some tasks are much slower with the JIT
20:46:45  * andythenorth reads
20:50:52  <glx> it's slower because it needs to compile each time
20:51:37  <andythenorth> that makes sense for chameleon page templates in my compile, which are called many times
20:51:48  <andythenorth> not sure how nmlc output stage works though
20:54:23  <frosch123> it's the most trivial part
20:54:52  <frosch123> it dumps the generated nfo code into a file, then reads the sprite cache and dumps that in the right order as well
20:55:27  * andythenorth wonders about learning to instrument it :P
20:55:54  <frosch123> you could put some print between writing the nfo and the sprites
20:55:59  <frosch123> so you know which part of the two is slower
20:56:01  <andythenorth> pypy being 5x slower is...interesting :P
20:56:12  <andythenorth> print is my horrible solution for all timings :)
20:56:21  <andythenorth> one day I will learn to program
20:57:33  <frosch123> what was the term? devloloper?
20:58:12  <andythenorth> yup
21:03:29  *** sla_ro|master has quit IRC
21:10:13  <andythenorth> hmm
21:10:24  <andythenorth> I can't see an nmlc option to drop the nfo comments
21:11:14  <andythenorth> there are 10k comments in iron-horse.nfo
21:11:54  <andythenorth> wondering what fraction of the 18.2MB nfo file they are :D
21:16:45  *** Arveen2 has joined #openttd
21:19:25  <nielsm> ugh hate when youtube tries to recommend me videos of fools trainsurfing
21:19:55  <nielsm> I always make sure to report the video then though (harmful or dangerous acts)
21:20:33  <andythenorth> unless it's the one in mauritania
21:20:38  <andythenorth> the ore train
21:23:56  *** Arveen has quit IRC
21:25:08  <andythenorth> oof because with pypy the parser is ~4s, and preprocessing is ~4s
21:25:28  <andythenorth> I'm not going to save much time by moving stacks of repeated switches to procedures
21:25:43  <andythenorth> unless it also affects the now slow output stage
21:26:23  <andythenorth> wondering if I can get filesize down though, 20MB for Iron Horse is quite offensive
21:26:29  <andythenorth> only 4MB is realsprites
21:27:13  <nielsm> 4 MB of image data and 16 MB of code?
21:27:17  <nielsm> that sounds excessive yes
21:27:37  <nielsm> there has to be a lot of repeated stuff
21:28:06  <andythenorth> there is
21:28:36  <andythenorth> there must be a tool that can analyse code similarity?
21:29:07  <nielsm> hmm, data compression tools? :)
21:29:12  <nielsm> (really, that's what they do)
21:30:00  <andythenorth> so a zip of the 18.2MB nfo file is 1.5MB
21:30:20  <andythenorth> a zip of the 10.3MB nml file is 616KB
21:30:34  <glx> text compress easily I think
21:30:46  <andythenorth> a zip of the 19.2MB grf is 1.4MB
21:30:54  <nielsm> yeah but that ratio is still bigger than general text
21:31:20  <andythenorth> so it's only 7% information?
21:31:23  <andythenorth> the rest is noise?
21:31:27  <nielsm> yeah
21:31:44  <andythenorth> nfo and nml are obviously prone to some boilerplate noise
21:31:52  <andythenorth> but seems excessive
21:32:08  <nielsm> nfo much less noise, since it's just an inefficient coding of the binary data
21:32:37  <glx> for me the important point is the size of the grf, nml anf nfo don't count
21:33:10  <glx> (from the final user POV)
21:33:28  <andythenorth> all those bananas transfers do add up though :D
21:33:35  <andythenorth> AWS fees
21:35:07  <milek7_> nielsm: why report though?isn't it usual that videos/movies often show dangerous stuff?
21:35:18  <milek7_> i even wonder if it detects that you hover miniature during reporting and shows you more of it.. ;P
21:35:31  <glx> if you can reuse switches as procedures you reduce size of all files
21:36:11  <glx> my macro branch won't reduce grf and nfo size, but will reduce nml
21:36:18  <nielsm> milek7_: apart from being illegal, it's stupidly dangerous, and those videos encourage others to try to perform the same
21:36:53  <nielsm> it's not professionals doing controlled action/special effects
21:37:50  <milek7_> dunno, I don't feel encouraged by watching stupid stuff to replicate it
21:38:00  <glx> some are
21:38:25  <andythenorth> a lot of the noise in Iron Horse is because OpenTTD can't handle the offsets for vehicles that have been flipped in the depot
21:38:33  <andythenorth> it's not 50% of the code, but it's a *lot*
21:38:54  <nielsm> I don't want the platform to help encourage other to try stupid stuff, and I don't want youtube enabling the uploaders by letting them put ads etc on the videos
21:38:57  <andythenorth> almost every graphics switch chain is entirely repeated
21:39:15  <andythenorth> simply to handle the flip / non flip offsets
21:40:05  <andythenorth> it also doubles the number of realsprites to be encoded, not sure if that adds filesize or not
21:40:46  <nielsm> can that grf tool someone posted on the forum yesterday (?) maybe be made to help trace which parts of the code bloat?
21:40:55  <andythenorth> it's a *lot* of logic and static data to handle flip in grf
21:41:07  <nielsm> or would it just be simpler to trace the code generation throughout the source
21:41:09  <andythenorth> for something that I would guess is a trivial transform from a table
21:41:33  <andythenorth> nielsm: in the case of Iron Horse, the bloat is obvious in the nml
21:41:41  <nielsm> ok
21:41:59  <andythenorth> 85KB of nml for a single open wagon
21:42:05  <nielsm> :s
21:42:18  <andythenorth> there are 13 open wagons
21:42:25  <andythenorth> so that's 1MB immediately
21:43:47  <nielsm> hmm... could we add a mechanism so GRFs can add custom (numbered) properties to vehicles/other items, that can then be accessed via pseudo-vars in action2 ?
21:44:11  <nielsm> so you can have a single shared action2 chain between all vehicles, and just have it look up the specific data for the vehicle in the vehicle's custom property table
21:44:16  <glx> it's called a newgrf param IIRC :)
21:44:28  <nielsm> it does exist?
21:44:30  <andythenorth> hmm I am banned from coop pastebin
21:44:37  <andythenorth> and now seems to be a scam site
21:44:48  <glx> well newgrd param can be abused for that I think
21:45:16  <andythenorth> extensible props?
21:45:25  <andythenorth> 'finally a use for those weird user bits'
21:45:31  <andythenorth> 'as long as you OR the whole consist'
21:45:33  <andythenorth>
21:45:52  <andythenorth> ^ spriteset repeition is expected, but there are twice as many just to handle flip
21:46:00  <andythenorth> the other repetition of switches is really obvious
21:46:50  <andythenorth> 30 or so random switches, all unique just in case I draw more than one cargo sprite :P
21:47:45  <andythenorth> so many repetitionso of "cargo_count*100/cargo_capacity"
21:47:45  <andythenorth> :)
21:49:31  <andythenorth> I can see multiple ways to use procedures to reduce this
21:49:45  <andythenorth> doesn't eliminate the silly duplication for flip state though :)
21:49:48  <andythenorth> just moves it
21:55:25  <glx> you could optimise loading speed switches ;)
21:57:02  <andythenorth> I could
21:57:08  <andythenorth> I probably will
21:57:18  <andythenorth> I am trying for some bigger, harder problems first though :)
21:57:29  <glx> will also increase running speed in openttd
21:58:13  <glx> but maybe nmlc should handle it
21:58:15  <andythenorth> what was the optimisation?
21:58:49  <andythenorth> use action 0, wrap them action [something]?
21:58:52  <glx> each open_car_pony_gen_6C_switch_loading_speed_by_cargo_X returns a constant
21:59:04  <glx> even if you check cargo class
21:59:18  <glx> so you could skip them and use the constant directly
22:00:13  <andythenorth> I could eliminate that in the compile
22:00:24  <nielsm> gn
22:00:28  <andythenorth> night nielsm
22:00:38  <glx> I think nmlc could analyse the switch return values and if they are all the same transform it to a constant
22:01:19  *** supermop_work has quit IRC
22:02:25  <glx> or not a constant but transform the switch into its return value in the caller
22:08:28  *** nielsm has quit IRC
22:10:30  <andythenorth> can't see what's wrong with this :)
22:10:40  <andythenorth> but it returns broken realsprites
22:11:09  *** supermop_work has joined #openttd
22:11:11  <andythenorth> the realsprites all exist and are named matching the switches
22:12:43  <glx> cargo_count*100/cargo_capacity can be handled as (cargo_count*100)/cargo_capacity or cargo_count*(100/cargo_capacity)
22:12:57  <glx> and in int world the result is different
22:13:05  <glx> I think
22:13:07  <andythenorth> oh I didn't use brackets :o
22:13:09  <andythenorth> oops
22:13:19  <andythenorth> I don't usually rely on all that BODMAS crap
22:13:58  <glx> in real world math the order is usually not important, but with integers and rounding :)
22:14:20  <andythenorth> hmm, but that should still return a result in range 0..5
22:14:26  <andythenorth> I am getting broken sprites
22:15:10  <glx> no default in last switch, dunno if it's important
22:15:42  <andythenorth> if I add one, it masks the broken by always returning the same realsprite
22:15:58  <andythenorth> it's as though the chain is returning early somewhere, with a bad value
22:16:45  <glx> indeed it should return a 0..5 value
22:19:04  <glx> I think the corresponding nfo can help
22:19:36  <glx> as nfo is a readable form of grf
22:19:48  <andythenorth> oof :)
22:19:56  <andythenorth> I'll find that in a minute
22:20:17  *** Flygon has joined #openttd
22:20:24  <glx> so we can see how this nml is translated
22:21:37  <andythenorth>
22:21:57  <andythenorth> I need to find the other part
22:23:05  <andythenorth> ok
22:25:14  <glx> nfo seems correct
22:25:44  <andythenorth> \wx8000 and \dx00000000 evaluate to same result?
22:25:57  <andythenorth> the first is the return value, the second is the checked range
22:27:02  *** asymptotically has joined #openttd
22:28:25  <glx> hmm
22:29:16  <andythenorth> I'm just checking Horse master to be sure this ever worked
22:29:22  <andythenorth> 99% sure I'd have noticed though :)
22:29:28  <andythenorth> broken sprites are obvious
22:29:45  <frosch123> i think var1c is completely wrong
22:30:09  <frosch123> it returns the term in the switch(...), not the actual "result"
22:30:17  <andythenorth> Horse master works
22:30:40  <andythenorth> relevant commit (is in a branch)
22:30:49  <frosch123> so nml may only use var1c if the procedure ends with "return"
22:30:59  <glx> yeah maybe I misunderstood "Because callback results are limited to 15 bits, to access the full 32 bit result you can read variable 1C instead (e.g. by and-ing the 7E result with 0 and then adding var. 1C). "
22:31:01  <frosch123> if it ends with "return 10", it must use the result of FE
22:31:24  <frosch123> quite magical :)
22:31:57  <frosch123> however, that is actually impossible for nml to decide
22:32:00  <andythenorth> "[8:21pm] glx: yeah it needs real world testing now"
22:32:01  <andythenorth> :)
22:32:17  <frosch123> the procedure may contain both "return" and "return 10"
22:33:11  <frosch123> so, only support 15bits?
22:33:29  <glx> so I remove the 1C part and let the writer decide if he wants to use the return or the last computed value
22:33:46  <frosch123> yes, i don't think there is a better solution
22:34:06  <glx> writer can do [call(), last_computed_value] I guess
22:34:46  <andythenorth> oh dear :)
22:34:49  <andythenorth> trusting authors :)
22:34:50  <frosch123> not sure whether that is reliable either. the nml coder has to make assumption about how nml encoded the stuff
22:35:58  <glx> anyway assume 15bit return, and if 32 bit is needed explicitely use last_computed in nml
22:36:13  <frosch123> i think, if someone really needs the 32bit result, we should extent ottd
22:36:15  <glx> safest solution
22:36:26  <frosch123> either add another var, or add some mechanism to change the meaning of 1c
22:37:19  <frosch123> or rather: change the FE call to not truncate the bis
22:39:52  <glx> luckily I separated the commits ;)
22:40:45  <andythenorth> even with the small use of procedures so far (3 instances)
22:40:53  <andythenorth> 18.4MB nfo -> 17.6MB nfo
22:41:03  <glx> impressive
22:41:21  *** supermop_work has quit IRC
22:41:25  <andythenorth> compile time is mostly unchanged
22:46:30  *** Wolf01 has quit IRC
22:46:36  <DorpsGek_III_> [OpenTTD/nml] glx22 updated pull request #66: Add: allow use of switches and random switches as procedures
22:46:45  <glx> ok removed the 1C
22:47:20  *** tokai|noir has joined #openttd
22:47:20  *** ChanServ sets mode: +v tokai|noir
22:47:47  *** andythenorth is now known as Guest11879
22:47:47  *** andythenorth has joined #openttd
22:48:18  <glx> ok removed the 1C (as you may have have missed it)
22:48:53  <andythenorth> I never figured out a simple way to update a PR I have checked out :P
22:49:35  <andythenorth> delete, fetch :P
22:49:37  <glx> hmm you need to set upstream IIRC
22:49:49  <glx> but yes delete and fetch again works too
22:50:57  *** hythlodaeus has joined #openttd
22:51:15  <andythenorth> ok so do I need to make the call differently now?
22:51:25  <glx> no
22:51:26  *** Guest11879 has quit IRC
22:51:37  <glx> no change on your side
22:51:49  <hythlodaeus> hi guys, I have a question regarding translation strings and the original English text
22:51:53  *** supermop_work has joined #openttd
22:52:16  <hythlodaeus> I'm currently trying to redo the portuguese translation, and while doing so I found some issues with the source text itself
22:52:32  <glx> except if your other calls were relying on the 32bit result
22:52:37  <Eddi|zuHause> what kind of issue?
22:52:57  <hythlodaeus> the text is inconsistent at times
22:53:00  * andythenorth installs nmlc to the correct python, might work better :P
22:53:26  <Eddi|zuHause> hythlodaeus: can you be more specific?
22:53:30  <hythlodaeus> the most notorious examples is strings that say "Ctrl toggles between" and "Ctrl+click to"
22:53:46  <hythlodaeus> they're technically two different sentences for the same thing
22:53:54  <glx> ah, I made it consistent in the french translation
22:54:10  *** tokai has quit IRC
22:54:11  <hythlodaeus> yeah I was thinking of doing the same for PT
22:54:19  <andythenorth> glx: works now
22:54:29  <glx> \o/
22:54:33  <hythlodaeus> but I think this also deserves to do a fix for the source text too
22:54:49  <glx> for that a PR is required
22:54:56  <hythlodaeus> PR?
22:55:03  <glx> pull request
22:55:03  <Eddi|zuHause> hythlodaeus: if you make changes to english.txt, please make a Pull Request on github
22:56:09  <hythlodaeus> supposing I do a PR fixing english strings and it gets accepted
22:56:29  <hythlodaeus> I supposed the modified strings would show up in the translation queue as "outdated" correct?
22:56:39  <hythlodaeus> *I suppose
22:57:01  <Eddi|zuHause> yes, you have to confirm them again
22:57:37  <hythlodaeus> that's brilliant. outdated strings is a great feature in eints that's lacking on most web translation interfaces
22:57:57  <hythlodaeus> most just delete the old translation altogether if an original string is updated
22:58:22  <glx> we delete the old translation if it's really incompatible
22:59:12  <glx> and not easily fixable by a search/replace
22:59:29  *** Samu has quit IRC
23:00:03  <hythlodaeus> well what I'm gonna do is to download the english language file, do all the fixes there and then submit a PR with it
23:00:33  <Eddi|zuHause> hythlodaeus: to make a PR, you have to make a github account, and clone the repository
23:00:44  <hythlodaeus> i have a github account
23:01:25  <Eddi|zuHause> you can then edit your clone of the repository, and then push that as a PR
23:01:44  <glx> better do it in a branch
23:01:51  <hythlodaeus> btw, my suggestion is we change all "Ctrl/Shift toggles" to "Ctrl/Shift+Click" since the latter is more specific
23:02:40  <Eddi|zuHause> sounds fine to me
23:07:48  * andythenorth wonders whether to drop randomised cargo sprites for, e.g. flat wagons
23:07:48  <andythenorth> they're not actually used currently, just supported in code
23:07:48  <andythenorth> saves 0.5MB :P
23:07:51  <andythenorth> with no negative effect on current  gameplay :P
23:09:15  <Eddi|zuHause> 0.5MB source code or compiled grf?
23:09:27  <andythenorth> nfo
23:09:58  <Eddi|zuHause> doesn't sound like a useful metric
23:10:11  <andythenorth> it's a vanity project
23:10:27  <glx> usually smaller nfo means smaller grf
23:10:30  <andythenorth> so far it has not reduced compile time or compiled grf size
23:10:50  <andythenorth> but I think it's worth continuing
23:11:18  <glx> but you have many nfo files merged for you grf IIRC
23:11:43  <andythenorth> it's nml -> nfo
23:12:00  <andythenorth> just one file
23:20:25  <andythenorth> ok bedtime, thanks for help glx
23:20:37  <glx> thanks for the real testing :)
23:21:17  *** frosch123 has quit IRC
23:21:43  *** andythenorth has quit IRC
23:22:02  *** asymptotically has quit IRC
23:22:07  *** supermop_work has quit IRC
23:22:44  <hythlodaeus> STR_RAIL_TOOLBAR_TOOLTIP_BUILD_RAILROAD_SIGNALS :{BLACK}Build railway signals. Ctrl toggles semaphore/light signals{}Dragging builds signals along a straight stretch of rail. Ctrl builds signals up to the next junction or signal{}Ctrl+Click toggles opening the signal selection window. Shift toggles building/showing cost estimate
23:22:46  *** supermop_work has joined #openttd
23:22:59  <hythlodaeus> good example of poor writing IMO
23:23:13  <hythlodaeus> I think this should be something like
23:23:57  <glx> this string has been updated multiple times I think
23:30:27  <hythlodaeus> {BLACK}Build railway signals.{}When a signal type is selected, ctrl+click switches between semaphore/light versions respectively{}Click+Drag builds signals along a straight stretch of rail.{}Ctrl+Click+Drag builds signals up to the next junction or signal{}Ctrl+Click on a placed signal switches between signal types. Shift+click shows costs estimate without making a purchase.
23:30:37  <hythlodaeus> this is my proposed edit
23:52:59  *** supermop_work has quit IRC
23:58:35  <Eddi|zuHause> 99% complete
23:58:59  <glx> what slow stuff are you doing Eddi|zuHause ?
23:59:23  <Eddi|zuHause> it's rebuilding the raid, for some reason

Powered by YARRSTE version: svn-trunk