Log for #openttd on 20th December 2019:
Times are UTC Toggle Colours
00:08:32  *** DorpsGek_III_ has quit IRC
00:11:21  <FLHerne> hythlodaeus: I think it's using "frequency" in [at least partially] the other sense, which is confusing in English as well :P
00:13:33  <FLHerne> Hm, now I'm not sure that's what was intended
00:22:06  *** Wormnest__ has quit IRC
00:49:54  <hythlodaeus> we'll see :)
00:50:16  <hythlodaeus> I just compiled 1.10 and i'm getting the following error when trying to run openttd
00:50:34  <hythlodaeus> Error: No available language packs (invalid versions?)
00:50:38  <hythlodaeus> can anyone help?
00:57:50  <hythlodaeus> nvm, forgot to do make install haha
01:08:36  *** Progman has quit IRC
01:09:42  *** Wormnest__ has joined #openttd
01:30:55  <glx> no need to make install, it's runable from .bin
01:57:19  *** hythlodaeus has quit IRC
03:18:03  *** D-HUND has joined #openttd
03:20:59  *** Wormnest__ has quit IRC
03:21:27  *** debdog has quit IRC
03:24:35  *** snail_UES_ has joined #openttd
03:48:50  *** glx has quit IRC
05:41:10  *** sla_ro|master has joined #openttd
06:44:36  *** snail_UES_ has quit IRC
07:14:12  *** andythenorth has joined #openttd
07:16:16  <andythenorth> yo
07:16:22  <andythenorth> Pikka: haz Civil?
07:16:35  <Pikka> very
07:17:31  <Pikka> just got to put the double track and track removal code back in ;)
07:17:39  <Pikka> and teach it to fish
07:19:27  <Pikka> it'll be done for christmas innit
07:19:28  *** tokai|noir has joined #openttd
07:19:28  *** ChanServ sets mode: +v tokai|noir
07:20:08  <andythenorth> super
07:20:25  <andythenorth> Oof, no fish in FIRS steeltown :)
07:20:27  <andythenorth> nvm
07:22:07  <andythenorth> Planes Are Broken Now And Must Be Fixed!
07:22:09  <andythenorth> or something
07:24:23  <Pikka> just remove them from the game probably
07:24:34  <Eddi|zuHause> PABNAMBF is a terrible acronym
07:25:45  <andythenorth> should I get an account on a reddit?
07:26:11  *** tokai has quit IRC
07:26:19  <Eddi|zuHause> no
07:26:21  <Pikka> no. or maybe.
07:27:07  <andythenorth> all the nice chat is there now
07:27:23  <andythenorth> I particularly enjoy the reddit thing of taking a screenshot using a bad camera phone
07:27:27  <andythenorth> it's quite common
07:27:35  <Eddi|zuHause> it's social media, and all social media naturally declines from an idealistic dreamhouse to an extremist cesspool
07:28:05  <andythenorth> it's because there's no actual fighting
07:28:14  <andythenorth> IRL, this can't happen in public spaces, because fighting
07:29:18  *** D-HUND is now known as debdog
07:33:47  <andythenorth> hmm can make trigger multiple processes in a controlled way, with blocking for completion on some?
07:34:53  <andythenorth> I have two pipeline stages which run in sequence, but are completely orthogonal
07:35:41  <andythenorth> I have 8 thread units, and python will obviously only max out one of them
07:48:26  <Eddi|zuHause> make -j8
07:50:33  <andythenorth> that's trivially easy then :D
07:53:08  <andythenorth> hmm, output in stdout suggests that's parallelising, but total run time is only marginally faster, difference might just be noise
07:53:12  <andythenorth> nvm :)
08:14:49  *** tokai has joined #openttd
08:14:49  *** ChanServ sets mode: +v tokai
08:21:44  *** tokai|noir has quit IRC
08:26:10  *** andythenorth has quit IRC
08:27:27  *** DorpsGek_III has joined #openttd
08:27:27  <DorpsGek_III> [OpenTTD/nml] Andrew350 opened issue #74: Speed values are slightly off when using metric units
08:43:34  <Pikka> yukkkkkk
08:49:02  *** HerzogDeXtEr has quit IRC
08:53:27  *** andythenorth has joined #openttd
08:58:29  <Pikka> huzzah
08:58:42  <Pikka> fixed it
08:59:36  <andythenorth> huzzah
09:00:19  <Pikka> don't && when you mean &, innit
09:03:31  <andythenorth> never
09:05:17  <Pikka> occasionally
09:07:54  *** WormnestAndroid has quit IRC
09:37:03  *** WormnestAndroid has joined #openttd
09:40:40  <DorpsGek_III> [OpenTTD/nml] planetmaker commented on issue #74: Speed values are slightly off when using metric units
09:49:48  <andythenorth> is it cat?
09:54:36  *** Progman has joined #openttd
10:14:48  <andythenorth> reduced iron-horse.nfo 1.2MB so far
10:14:50  <andythenorth> using procedures
10:16:00  <planetmaker> is it written in plain nfo?
10:16:13  <andythenorth> no no
10:16:31  <andythenorth> nml -> nfo -> grfcodec
10:18:11  <andythenorth> :)
10:18:20  <DorpsGek_III> [OpenTTD/nml] planetmaker opened pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD
10:18:57  <planetmaker> ah, I see
10:19:17  <andythenorth> it's faster for the common case of 'only sprites changed'
10:19:28  <andythenorth> but nmlc writes nfo *much* slower than grf
10:19:42  <planetmaker> he. As expected and asked in the original PR: regressions fail :D
10:20:00  <andythenorth> nmlc grf output is 10x faster than nfo output
10:20:15  <planetmaker> yep... 10x less to write :)
10:21:32  <andythenorth> it's interesting that pypy nmlc writes nfo 5x slower than py38 nmlc
10:21:52  * andythenorth checks that result again
10:25:08  <andythenorth> @calc 9.5 / 1.7
10:25:08  <DorpsGek> andythenorth: 5.58823529412
10:25:11  <andythenorth> yeah 5x
10:25:14  <andythenorth> oof
10:30:23  <DorpsGek_III> [OpenTTD/nml] planetmaker updated pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD
10:51:11  <andythenorth> oof
10:51:24  <andythenorth> I need a simple maths scheme, so I can resolve to numbered spritesets
10:51:47  <andythenorth> based on n vehicle variants, 2 loading states, and 2 livery options
10:52:29  <andythenorth> that would be easy to encode into bytes in a dword or something
10:52:38  <andythenorth> what about with integer maths though?
11:11:29  <peter1138> Why does my Mozilla Thunderbird keep locking up?
11:17:05  <andythenorth> is it the email client?
11:19:55  <peter1138> That it is, yes.
11:20:39  <peter1138> Also, my commute was somewhat damp today :/
11:20:54  <andythenorth> I got wetted on yesterday
11:20:56  <andythenorth> did not like
11:30:12  <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD
11:37:11  *** floodious has joined #openttd
11:37:47  <floodious>  if anyone's up/active at the moment, i've noticed creating lakes using the river tool is extremely manual, and before i grab the git tree and try to look into it myself;  have there been any attempts to implement a waterways + rivers > floodfill "+height levels" tool? (codewise is that more difficult than applying floodfill to a 8 bpp bitmap?)
11:39:36  <floodious> since building a scenario using a heightmap generated from realistic data gets you part way there quite well despite the limitations of resolution (realistic scale is tricky), it's possible to use known lake water levels in the perfectly flat regions of the lakes to flood-fill the water accurately, but no implementation exists for this (to my knowledge?)
11:40:14  <floodious> doing this manually on a 4k x 4k is driving me nuts
11:41:03  <DorpsGek_III> [OpenTTD/nml] frosch123 commented on pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD
11:41:25  <Pikka> sounds like a fun project, floodious
11:42:21  <floodious> well assuming i can get the pointer/reference to the river (one value in the tile type map?) and height maps, it would be a copy-paste job from my existing floodfill code
11:42:39  <floodious> mostly gui code as usual, adding the buttons/menus to the UI
11:43:07  <LordAro> i remember a vastly improved river generator patch lurking somewhere on the forums, but nothing for manual creation
11:43:19  <floodious> but i figured someone who knows the code might be able to do it at 10x the speed and "correctly" whereas I'll make a mess :)
11:43:36  * floodious refactors EVERYTHING
11:46:32  <DorpsGek_III> [OpenTTD/nml] frosch123 commented on pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD
11:47:59  <floodious>
11:48:06  <floodious> floodfill c++
11:48:18  <milek7_> maybe related:
11:49:48  <LordAro> floodious: unfortunately, the algorithm isn't the hard part :)
11:49:49  <floodious> yeah that looks like they built a tool to externally read from multiple source bitmaps (height, river, forest, ...) and build the scenario file
11:50:06  <floodious> aro; i know that :)
11:50:25  <floodious> hardest part is the damn UI, 90% of the time
11:55:44  <DorpsGek_III> [OpenTTD/nml] planetmaker commented on pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD
12:01:21  <floodious> ah, openttd is still in c
12:02:36  <planetmaker> c/c++...
12:03:07  <floodious> well, there are whole c++ projects, then there are "c with classes" that evolve slowly, and openttd is the latter apparently
12:03:10  <planetmaker> it's somewhat currently being updated to c++11
12:03:23  <floodious> running into old function-based c code makes things way harder
12:03:43  <planetmaker> some parts... are simply optimized for speed
12:04:25  <floodious> well in correctly implemented c++ you should get identical machine code output, the code is just 1/10th the size
12:05:23  <floodious> for example the floodfill thing i posted is really bad quality, but the c-version with everything done manually would easily be 5x to 10x
12:06:12  <milek7_> if 'whole c++ projects' are boost-style template hell, then i rather prefer C..
12:06:24  <floodious> no, that's the opposite of proper c++ :)
12:07:09  <floodious> but "template hell" vs. correct application of templates, templates are a language feature designed to facilitate reliable code reuse, which means you can reduce the overall size of the code making it easier to maintain while generating identical machinecode output
12:07:31  <floodious> anyway i already said that with /me refactors everything
12:09:34  <andythenorth> nfo was 18.2MB, now 16.7MB
12:09:38  <andythenorth> procedures winning
12:09:49  <andythenorth> final grf size is unchanged, compile time barely changed
12:16:04  *** andythenorth has quit IRC
12:19:21  <planetmaker> nmlc andythenorth.nml -c -p2 -l unfinished --quiet --clear-orphaned --verbosity=4 -o andythenorth.nfo -o andythenorth.grf
13:16:47  <floodious> the "c" thing is mostly, and I've verified it more now looking through the source I'd need to change to implement the floodfill stuff (~1/3 there reading) is ...
13:19:04  <floodious> that good object-oriented code is arranged in a more hierarchical structure using multiple levels of namespaces. so functions like SetTileHeight(tile, height) become more like map[point(x, y)].height = height;
13:20:00  <floodious> but re: 1/3rd, I haven't even figured out where the heck SetTileHeight() is or what it does
13:22:34  <floodious> tile_map.h inline global accessing global _m (map) [tile_index].height
13:22:46  <floodious> very oldschool c style :)
13:32:28  <LordAro> more like "barely converted from assembly" c style ;)
13:32:41  <floodious> yeah of course for those of us who know the history :)
13:45:26  <FLHerne> floodious: tbh, I don't find `SetTileHeight(tile, height)` to be particularly unreadable :P
13:48:54  <floodious> no it's more a matter of who uses it, the fact _m is a global pointer and so there is no way to be certain the path it's inherited and such... like main() { map_t map; map.allocate(x, y); run_game(map); } I mean, forget the proper term for such a structure
13:49:18  <floodious> i'm cloning the repo anyway and I'll look in more detail
13:49:44  <floodious> trying to understand the overall structure of the program is quite hard, "spaghetti code" as they say
13:51:25  <FLHerne> The core really is just structured like a C program; there's a bunch of global state, and a mainloop that calls functions that modify the state
13:51:30  <planetmaker> you cannot expect to understand a 300k LOC programme in a day in-depth.
13:52:03  <floodious> i'm one of the anti-globals people
13:52:33  <floodious> anti- a lot of things, but it's not a critique just saying, i understand what makes the floodfill stuff hard
13:52:53  <planetmaker> might be for you, if you struggle to understand the structure
13:53:08  <floodious> nah the sourcecode helps
13:53:22  <FLHerne> Trying to understand the OTTD core in an OOP sort of way isn't going to work, because it just isn't that way
13:53:38  <floodious> i'm not trying to, and understanding isn't the issue
13:53:51  <floodious> i'm looking at creating a dupe and refactoring it into an OOP format
13:54:09  <FLHerne> That sounds like a very big project
13:54:15  <floodious> average day for me
13:54:28  <floodious> let's see if it happens :)
13:54:45  <FLHerne> s/day/three-month-holiday/ :P
13:55:00  <floodious> some projects i've worked on for the past 20 years
13:55:01  <FLHerne> (maye)
13:55:59  <floodious> depending where you mark the start... i mean things evolve and transform but i'd say my longest lived project is ~22 now, 1997
13:56:15  <FLHerne> If you're rewriting all the stuff anyway, you might be interested in Cirdan's "New Map Features" branch
13:56:24  <FLHerne> thread:
13:56:43  <floodious> problem not, but such things can be merged in across various branches
13:56:48  <floodious> problem/probably
13:56:59  <floodious> anything that makes the existing code any more complex would be a waste for me
13:57:02  <planetmaker> <-- I would more recommend that branch by michi
13:57:07  <FLHerne> IIRC, it doesn't make the map array non-global, but it does structure it in a much saner way
13:57:52  <planetmaker> damn... that branch has aged, too
13:57:53  <FLHerne> floodious: Despite the name, the "new features" are based on quite a comprehensive reorganization of the map structures
13:58:08  <floodious> i'll be focusing on the core/main branch
13:59:40  *** snail_UES_ has joined #openttd
14:07:25  *** Flygon has quit IRC
14:07:27  <planetmaker> but my understanding is correct: you started with river generation and now go for entire map access refactoring? :D
14:08:08  <floodious> no, things come in layers
14:09:22  <floodious> i don't want to muddy up the existing code, so i'll look at first creating a branch that simply implements things the mad-C-wizard way, then as I clean that up I'll look at what's beneficial or not until I'm personally satisfied with the result... and all that stuff could get merged back in (manually of course) from my branch once completed (if so)
14:10:51  <floodious> once i start peeling this onion though there will be tears for sure
14:15:29  *** sla_ro|master has quit IRC
14:39:10  *** snail_UES_ has quit IRC
14:45:15  *** Hythlodaeus has joined #openttd
14:45:54  <Hythlodaeus> Hi guys, I'm doing good progress with improving the English tooltips text. I was wondering if you guys would like me to add the hotkeys to the tooltips as well
14:46:59  <nielsm> you mean "soft" hotkeys that properly look up the configured key, right?
14:47:08  <michi_cc> Hythlodaeus: Most hotkeys can be configured (even if it's only a config file and not a GUI).
14:48:25  <Hythlodaeus> is it possible for me to pull up a script argument for that?
14:48:30  <Hythlodaeus> if so that would be lovely
14:48:50  <michi_cc> Do we still keep a "good first things" list around? Cause a hotkey GUI could probably be an entry for that.
14:49:14  <nielsm> showing the key in the tooltip would need a new string formatting code
14:49:17  <Eddi|zuHause> michi_cc: iirc there's a github tag
14:49:48  <Hythlodaeus> can any of you guys add that? I doesn't sound like a lot of work
14:50:05  <nielsm> having a string formatting code that looks up and shows the hotkey for something could probably also be used in GS (tutorial and such)
14:50:18  <Hythlodaeus> and I would move on to add soft hotkeys to tooltips ASAP
14:50:26  <Hythlodaeus> which would be very nice IMO
14:56:42  <Hythlodaeus>
14:56:50  <Hythlodaeus> just so you guys have an idea of what i am doing
14:57:14  <Hythlodaeus> standardizing instructions for all shift+ and ctrl+ shortcuts
14:57:22  <Hythlodaeus> improving descriptions
14:57:38  <Hythlodaeus> adding descriptions to tooltip that did not have them before
14:58:01  <Hythlodaeus> and I'm gonna standardize capitalization afterwards
14:58:26  <Eddi|zuHause> nielsm: looking up from the tag would be tricky, but it could just be pushed onto the text stac
15:02:10  <nielsm> Eddi|zuHause: that would actually need GUI elements to keep a third data item, name of the hotkey to show in the tooltip
15:02:24  <nielsm> though it could just be a const char *
15:02:50  <Eddi|zuHause> nielsm: some key names need to be translatable
15:03:31  *** andythenorth has joined #openttd
15:03:36  <nielsm> I was thinking using the hotkeys.cfg (or whatever) name of the key as a string on the GUI control that owns the tooltip, and then have logic in the string formatting to look up the key names
15:04:15  <michi_cc> String codes can have parameters, which means the hotkey code could also be encoded into the string itself.
15:04:41  <nielsm> also a possibility
15:04:46  *** supermop_work has joined #openttd
15:05:18  <nielsm> e.g. {CMD_HOTKEY:build_railroad} or whatever
15:05:27  <andythenorth> yo
15:05:27  <nielsm> ?
15:05:47  <supermop_work> yo andythenorth
15:05:53  <Hythlodaeus> howdy
15:07:08  <supermop_work> pro tip: don't pick regulate for karaoke with coworkers
15:07:40  <nielsm> ohoho
15:07:56  *** WormnestAndroid has quit IRC
15:08:01  *** WormnestAndroid has joined #openttd
15:08:01  <Hythlodaeus> is that the mobile TTD?
15:08:07  <nielsm> transport fever 2
15:08:24  <Hythlodaeus> cheap interface
15:08:40  <Hythlodaeus> nice ref tho
15:09:27  <Hythlodaeus> wait, regarding dynamic hotkeys
15:09:45  <Hythlodaeus> how would it present keys with longer names such as Space Bar
15:09:51  <Hythlodaeus> or page up
15:10:05  <nielsm> those will need translatable strings
15:10:19  <Hythlodaeus> preferable abbreviated
15:10:22  <nielsm> which the string formatting code will need to select
15:10:46  <Hythlodaeus> bc otherwise they would a lot of space in the tooltip window
15:11:47  <Hythlodaeus> i would suggest 4 char abbreviations
15:12:38  <floodious> "space" is fairly short, five chars
15:12:59  <Hythlodaeus> 5 chars then
15:12:59  <floodious> "shift", "capsLK" is six
15:13:13  <Eddi|zuHause> how would you fit "Bild↑" into 4 characters?
15:13:16  <nielsm> okay need to play "can't get there from here" for trf2 for a moment... the "clone vehicle" function loves building the clone in wrong depots
15:13:30  <nielsm> where the new vehicle can't possibly enter the route it needs to
15:13:37  <Hythlodaeus> shft
15:13:43  <Hythlodaeus> spc
15:13:54  <Hythlodaeus> capL
15:14:07  <Eddi|zuHause> Hythlodaeus: that is truely horrible
15:14:11  * floodious is a member of the anti-abbreviations organization
15:14:19  <floodious> i'm anti- a lot of stuff
15:14:26  <floodious> ex: anti-work
15:14:36  <andythenorth> anyone see a var for 'vehicle is loading / unloading'? (or inverse )
15:14:36  <andythenorth> there's only 'unloading' which doesn't do what I want
15:14:36  <andythenorth> maybe an 80+?
15:14:41  <Hythlodaeus> right, 5 letters then?
15:14:55  <floodious> now you see this is ambiguous, was I previously anti-work or was it given as an example
15:15:26  <nielsm> Hythlodaeus all those key names would become new strings on their own, so you'd have to define e.g. STR_KEYNAME_SPACE  and STR_KEYNAME_PREFIX_SHIFT
15:15:53  <Eddi|zuHause> Hythlodaeus: it doesn't make any sense to put up an arbitrary limit to the number of letters
15:16:14  <floodious> it's good to pad spaces for symbols, since in UTF-8 you might want chinese characters for example, or other languages that are very hard to represent in the same space as "N US-ASCII"
15:16:28  *** WormnestAndroid has quit IRC
15:16:32  <floodious> using a unit like "em"s
15:16:41  *** WormnestAndroid has joined #openttd
15:16:56  <Hythlodaeus> point is that if you want hotkeys on tooltips you do require abbreviations
15:17:00  <nielsm> Hythlodaeus: also remember that OTTD does line breaking and can automatically widen windows to fit text
15:17:32  <Hythlodaeus> I'm aware, but there's a point where tooltip window can become too big and look ugly
15:18:00  <Hythlodaeus> and I'm already at the limit with some. i.e, the first screnshot i posted with the build signals tooltip
15:18:16  <floodious> the more general rule would be "try to aim for 4 em widths"
15:18:27  <floodious> so "MMMM" is almost == "space"
15:19:00  <Hythlodaeus> we could have two types of strings for keys tho
15:19:15  <Hythlodaeus> full name, for future GUI interface
15:19:19  <Hythlodaeus> and one abbreviated
15:21:23  <planetmaker> and "space"... is not as short in every language as in English :)
15:21:35  <floodious> abbreviations are often quite arbitrary, so there is no general purpose set of heuristics that would allow you to write an algorithm to produce them automatically, and they are often very subjective and tend to become redundant overhead in any process
15:22:11  <Hythlodaeus> i need abbreviations for hotkey tooltips tho
15:22:13  <floodious> not to mention "space" implies rockets and the moon
15:22:42  <floodious> another option depending upon facilities is often to use "tiny font"
15:23:06  <floodious> so "space" in the same width in pixels as "spc"
15:23:21  <Hythlodaeus> wouldn't it be barely readable?
15:23:23  <floodious> that's better suited to high resolution (ppi) devices
15:23:38  <floodious> yes, the choice of "how tiny" is determined by what's minimally readable
15:23:43  <Hythlodaeus> can you post an example? I haven't seen tiny font in game yet
15:23:50  <floodious> such as a 3x5 font in pixels
15:24:04  <Eddi|zuHause> Hythlodaeus: zoom out, the town names turn to tiny font at some point
15:24:21  <nielsm> yes zoomed all the way out, all signs on the map are shown in tiny font
15:24:26  <planetmaker> I'd very much appreciate a GUI-scaling along the lines of 1x, 1.25x, 1.5x, 2x, 3x... instead of our really coarse one :) (yes, totally unreleated)
15:24:27  <nielsm> the music player also uses tiny font
15:24:47  <nielsm> and the minimap legend
15:24:49  <Eddi|zuHause> the date on the newspaper is tiny font
15:25:17  <Hythlodaeus> I see, that's quite acceptable actually
15:25:35  <Hythlodaeus> I can also color it red so it pops out a bit more
15:26:39  <nielsm> don't do that, it's not necessary
15:27:10  <Hythlodaeus> would be nice tho. i like colored hotkeys, but I'll show a preview of both eventually so you can pick
15:27:14  <nielsm> if you have MS Office installed, you can turn on hotkeys in its tooltips somewhere, use that as a reference
15:27:26  <Eddi|zuHause> i'd say the opposite, the hotkey should be more shaded than the regular text
15:27:30  <Hythlodaeus> libreoffice
15:27:34  <floodious> they often use bold+tiny, but at low res that's not possible
15:28:24  <floodious> of course if a bit of text comes with an associated set of flags, you could set bold+tiny and at low res it would automatically ignore the bold part
15:28:37  <floodious> or use a brighter/high contrast color in place of bold
15:28:54  <Eddi|zuHause> we don't have any concept of boldness
15:29:14  <Hythlodaeus> Eddi|zuHause:  thank sounds like we're all cowards here
15:29:19  <floodious> how unbold
15:29:20  <Hythlodaeus> *that
15:30:08  <andythenorth> no loading/unloading var then? :)
15:30:34  <Hythlodaeus> ok, i like where this is going regardless. I'll keep finishing the main descriptions for tooltips over the coming days. would you like me to submit an issue regarding this hotkeys thingy?
15:31:04  <Hythlodaeus> and if so, do you think a solution by the end of next week would be feasible?
15:32:00  <andythenorth> 80+ 0A? bit 3
15:32:07  * andythenorth doesn't trust 80+ vars
15:35:48  <planetmaker> this NewGRF update turned out somewhat larger...
15:35:52  *** HerzogDeXtEr has joined #openttd
15:35:59  <planetmaker> 693MiB download...
15:39:03  <andythenorth> oof
15:47:37  * andythenorth wonders if this could be merged?
15:47:37  <andythenorth>
15:47:42  <andythenorth> checks failed eh
15:48:00  <andythenorth> I have an increasingly large Iron Horse branch that depends on it
15:48:59  *** lpx is now known as Guest12040
15:49:15  *** lpx has joined #openttd
15:50:52  *** Guest12040 has quit IRC
15:55:38  <Eddi|zuHause> <nielsm> okay need to play "can't get there from here" <-- i haven't seen that problem, but i noticed that when you clone a train, it just check whether it can reach one of the stations in the line, not the correct platform that line uses. so it uses a random other platform, and must get back onto the line from there
16:01:09  *** Wormnest__ has joined #openttd
16:20:36  <floodious> probably the entire state isn't cloned but rather portions are init (same as upon creation from scratch) so it gets a zero instead of copying from the source
16:21:21  <floodious> although i haven't looked at the code enough to say, some of those vars may be running state, not possible to duplicate unless position + allocations + etc are all duplicated too
16:21:51  <nielsm> floodious: we are talking about a different game here :) transport fever 2
16:22:02  <floodious> same thing though
16:22:17  * andythenorth wonders where to find var 0A in ottd src
16:22:17  <nielsm> unless you happen to work at urban games, of course
16:22:20  <andythenorth> unrelated
16:22:47  * andythenorth really wants to delete a confusing spritegroup and specify spritesets directly
16:23:01  <floodious> well, they have state + running state too, otherwise you couldn't have a configuration (like orders) and position on the map + direction + heading + etc
16:23:48  <Eddi|zuHause> floodious: i don't see how that has anything to do with the issue
16:24:07  <floodious> you'd have to locate the bug in the code to
16:24:21  <andythenorth> how is loading/unloading an actual order state?
16:24:38  <floodious> it's saved somewhere and associated with an object, that's called state
16:24:39  * andythenorth looking at 0A bit 03
16:25:11  <nielsm> floodious it has nothing to do with that at all though, depots in trf2 are not bound to lines or vehicles
16:25:13  <floodious> running or runtime state is different, such as the position in a song that's currently playing, you can't simply copy the position to a different song without transformation into a portable time format like seconds
16:25:23  <Eddi|zuHause> andythenorth: we have that, but it cannot distinguish between loading and unloading phase of the order
16:25:23  <nielsm> (unless the vehicle is assigned to the depot, in which case it is not on a line)
16:25:44  <floodious> since 412 seconds in one song is right on the beginning of a bar, but in another it's not aligned to anything at all
16:25:47  <andythenorth> Eddi|zuHause: I just want anything that distinguishes between load / unload and 'everything else'
16:26:08  <andythenorth> this is just to open / close doors on trains
16:26:15  <Eddi|zuHause> floodious: you're talking absolute nonsense
16:26:30  <floodious> abstract you mean
16:26:47  <andythenorth> I can open / close doors with spritegroups, but they are adding boilerplate that I'm trying to delete
16:26:59  <andythenorth> and confusingly nml syntax is 'loaded' for 'not loading / unloading'
16:27:01  <Eddi|zuHause> andythenorth: then the spriteset has you covered, it has different sprites for loading (=at station) and loaded (=everywhere else)
16:27:10  <nielsm> floodious you don't understand the issue we are talking about, and we perfectly understand the concepts you are trying to explain
16:27:24  <Eddi|zuHause> andythenorth: no action2 stuff needed
16:27:46  <andythenorth> I know, I just want to use action 23
16:27:49  <andythenorth> action 2 *
16:27:57  <floodious> i don't see what there is to understand, it's state that isn't copied completely, or something that state plays no part in deciding
16:28:12  <floodious> either way a bug if the intent is duplication of behavior
16:28:34  * andythenorth thinks there must be something here
16:29:04  <Eddi|zuHause> floodious: being "nonsense" has nothing to do with being true or not, but with it being totally unrelated to the problem
16:29:17  <nielsm> the state is specifically _not_ supposed to be copied, the game is supposed to take a vehicle configuration and create a new vehicle with the same configuration, it does that correctly. what it does not do is place the newly created vehicle in a depot that allows the new vehicle to pathfind to the route it is being assigned
16:29:22  <floodious> you mean the problem of behavior being different?
16:29:26  <andythenorth> @seen frosch123
16:29:26  <DorpsGek> andythenorth: frosch123 was last seen in #openttd 17 hours, 42 minutes, and 11 seconds ago: <frosch123> planetmaker: i think the conclusion was, that the tree should feature all settings, while the mapgen gui duplicates those that need to be set at game start
16:29:42  <planetmaker> :P
16:29:53  <Eddi|zuHause> floodious: or the problem of not understanding what the problem is?
16:30:18  <floodious> nah, it may be that the issue is the hard state doesn't include the depot or route at all
16:30:34  <Eddi|zuHause> right, you're going on my ignore list. bye
16:30:34  <floodious> so it's impossible to duplicate, due to being a part of runtime state
16:30:55  <nielsm> the state of the vehicle includes the route, but nothing in a route or a vehicle points to a home depot of any kind
16:31:03  <floodious> there you go
16:31:30  <Eddi|zuHause> nielsm: which would be pointless, as that depot might not even exist anymore at the time of cloning
16:31:32  <nielsm> that's what I have been explaining the entire time
16:31:35  <nielsm> yes
16:32:00  <andythenorth> there is FE bit 1, but that's weird
16:32:07  <floodious> it's a problem that's impossible to solve without fully duplicating runtime state, cloning in the physical sense (same position, heading, hysteresis, etc)
16:32:10  <Eddi|zuHause> but i think pathfinding to (station+platform) instead of just (station) would probably solve the issue
16:32:13  <nielsm> the issue is that the game does not check whether the depot it chooses for new vehicle creation can pathfind to the route of the vehicle and stop at the correct platforms
16:33:00  <Eddi|zuHause> however, i usually build my stations so you can reach lines from any platform, so the issue didn't come up for me
16:33:30  *** gelignite has joined #openttd
16:33:32  * andythenorth wonders what the spritegroup checks
16:33:59  <Eddi|zuHause> andythenorth: it checks for OT_LOADING, probably
16:34:11  <Eddi|zuHause> (name might be different)
16:34:26  * andythenorth trying to find where action 2 is defined in src
16:34:47  <Eddi|zuHause> andythenorth: newgrf_train.cpp probably
16:35:02  <andythenorth> looks like maybe newgrf_spritegroup.cpp
16:35:12  <Eddi|zuHause> andythenorth: that's probably too generic for you
16:35:35  <andythenorth> yup
16:36:10  <andythenorth> I already looked through newgrf_engine.cpp couldn't see it
16:36:25  <andythenorth> oh maybe this
16:36:26  <andythenorth> 	bool in_motion = !v->First()->current_order.IsType(OT_LOADING);
16:36:51  <andythenorth> so the confusing terminology originates there :)
16:37:04  <andythenorth> assumes that 'loaded' is a synonym for 'in motion'
16:37:25  <Eddi|zuHause> "confusing terminology" is likely inherited from TTD or patch
16:37:36  <andythenorth> yup makes sense
16:37:53  <andythenorth> so I think this is var 0A bit 3
16:38:06  <andythenorth> but I'm not sure if that covers all cases
16:38:10  <Eddi|zuHause> var 8A you mean
16:38:46  <andythenorth> yes, it's 80+
16:38:54  <andythenorth> enum OrderType : byte { looks relevant
16:39:04  <andythenorth> OT_LOADING = 3,
16:39:58  <andythenorth> ok, so nml var[0x8A, ??, 0x??]
16:40:10  <andythenorth> I need bit 3, it's a word
16:40:21  <Eddi|zuHause> var[0x8A, 3, 1] probably
16:40:39  <andythenorth> thanks
16:40:45  <Eddi|zuHause> value should be 0/1
16:45:54  <andythenorth> seems to work thanks :D
16:50:47  <andythenorth> wow spritegroups in nml scale horribly
16:50:57  <andythenorth> I've removed 2 spritegroups (repeated many times though)
16:51:06  <andythenorth> saves ~600KB from a 9MB nml file
16:59:23  *** frosch123 has joined #openttd
17:01:26  *** sla_ro|master has joined #openttd
17:03:03  *** Hythlodaeus has quit IRC
17:05:21  <andythenorth> hmm, I was mistaken, this doesn't work var[0x8A, 3, 1]
17:05:36  <andythenorth> do I need to mask it or something?
17:06:25  <frosch123> 3 and 1 are already the mask
17:07:13  <andythenorth> so that should get me bit 3 of 80+ 0A?
17:07:33  <frosch123> wtf are you doing with orders?
17:07:42  <andythenorth> eliminating spritegroup use
17:08:09  <andythenorth> spritegroup defines 'loaded' as not OT_LOADING
17:08:39  <andythenorth> I have to repeat the spritegroups a ridiculous number of times in nested loops, where I could just use a procedure result once
17:08:49  <frosch123> you can also use spritegroups as procedures
17:09:08  <andythenorth> that's interesting
17:09:10  <frosch123> at least in nfo, not sure whether nml is more strict
17:09:45  <andythenorth> so could I get that to just yield 0 / 1?
17:10:06  <andythenorth> I just need to open some doors when loading / unloading :P
17:10:17  <andythenorth> it shouldn't take 600KB of nml to do that :)
17:11:20  <nielsm> straight NFO allows calculated sprites, right? i.e. taking a sprite number and adding some offset to it to get a later sprite
17:11:22  <frosch123> does "loaded: return 1; loading: return 0 ;" work?
17:11:25  <nielsm> does NML allow that?
17:11:37  <frosch123> nielsm: no, nfo does not allow that
17:12:04  <frosch123> except in places where registers are allowed, but then nml also supports it
17:13:17  * andythenorth tests
17:13:24  <andythenorth>  nmlc ERROR: "generated/iron-horse.nml", line 1267: Expected a sprite set reference
17:13:27  <andythenorth> 'nope'
17:13:42  <frosch123> so we need to patch nml :)
17:14:10  <andythenorth> PR 66 again? o_O
17:14:49  <frosch123> no, it's not related to procedures
17:15:10  <andythenorth> hmm
17:15:23  <andythenorth> I need to chain to a second switch to check % load
17:15:28  <andythenorth> so that doors close when full
17:16:04  <frosch123> well, in theory "loading: return 0, return 1, return 2;" :)
17:16:22  <andythenorth> yup
17:16:27  <Eddi|zuHause> andythenorth: not sure why this added complexity would help anything
17:16:28  <frosch123> but yes, the "return" with "," sequence is weird
17:16:34  <andythenorth> nmlc dislikes 'return' btw
17:16:40  <andythenorth> so yeah
17:16:42  <andythenorth> patch time
17:17:01  <andythenorth> Eddi|zuHause: it's adding nothing except smaller input file and my code is easier to read
17:17:15  <andythenorth> the resulting grf filesize is stubbornly unchanged
17:17:22  <Eddi|zuHause> andythenorth: on the possible cost of runtime performance?
17:17:25  <andythenorth> and the improved compile speed could just be variation
17:17:34  <floodious> a spritegroup is like an array of handles/references to sprites, right? so it allows you to index into the group
17:17:47  <floodious> but why would such a thing add such a significant size to the result
17:17:51  <planetmaker> my_sprite_set[loading] ?
17:17:52  <andythenorth> Eddi|zuHause: same var though?  the spritegroup doesn't have any obvious caching
17:18:06  <andythenorth> runtime effect is negligible / none?
17:18:29  <Eddi|zuHause> andythenorth: i have no profiling data, but i expect action2 to be slower
17:18:35  <andythenorth> overhead?
17:19:14  <andythenorth> I also remain curious why var[0x8A, 3, 1] isn't working as expected
17:19:33  <andythenorth> far as I can tell it's returning 0 at all times
17:22:19  * andythenorth tries PARENT instead of SELF
17:22:30  <andythenorth> nope
17:26:09  <Eddi|zuHause> andythenorth: it definitely has to be PARENT
17:27:17  <frosch123> andythenorth: where did you get the 3 and 1 from?
17:27:39  <andythenorth> bit 3?
17:27:41  <andythenorth> I asked eddi :)
17:27:54  <andythenorth> oh is broken, and I am banned from coop pastebin for abuse
17:28:18  <frosch123> you need var[0x8A, 0, 0xF] == 3
17:28:40  *** glothit7ok[m] has quit IRC
17:28:40  *** natmac[m] has quit IRC
17:28:40  *** josef[m] has quit IRC
17:28:40  *** dude[m]1 has quit IRC
17:28:40  *** MSavoritias[m] has quit IRC
17:28:40  *** pothyurf[m] has quit IRC
17:28:40  *** labs[m] has quit IRC
17:28:40  *** ciet[m] has quit IRC
17:28:40  *** nolep[m] has quit IRC
17:28:40  *** backtu[m] has quit IRC
17:28:40  *** yoltid[m] has quit IRC
17:28:40  *** osvaldo[m] has quit IRC
17:28:40  *** olivier[m] has quit IRC
17:28:40  *** cawal[m] has quit IRC
17:28:40  *** jact[m] has quit IRC
17:28:40  *** yur3shmukcik[m] has quit IRC
17:28:40  *** dag[m] has quit IRC
17:28:40  *** buggeas40d[m] has quit IRC
17:28:40  *** ad5twoknebor[m] has quit IRC
17:28:40  *** nartir[m] has quit IRC
17:28:40  *** khavik[m] has quit IRC
17:28:40  *** albert[m] has quit IRC
17:28:41  *** lapav[m] has quit IRC
17:28:41  *** ookfof[m] has quit IRC
17:28:41  *** fjodor[m] has quit IRC
17:28:41  *** fiddeldibu[m] has quit IRC
17:28:41  *** iarp[m] has quit IRC
17:28:41  *** ircer[m] has quit IRC
17:28:41  *** grag[m] has quit IRC
17:28:41  *** elliot[m] has quit IRC
17:28:41  *** pina[m] has quit IRC
17:28:41  *** ist5shreawf[m] has quit IRC
17:28:41  *** josef[m]1 has quit IRC
17:28:41  *** Heiki[m] has quit IRC
17:28:41  *** Corns[m] has quit IRC
17:28:41  *** einar[m] has quit IRC
17:28:41  *** arron[m] has quit IRC
17:28:41  *** natalie[m]1 has quit IRC
17:28:41  *** johanna[m] has quit IRC
17:28:41  *** joey[m] has quit IRC
17:28:41  *** mrtmol[m] has quit IRC
17:28:41  *** julie[m] has quit IRC
17:28:41  *** robert[m]2 has quit IRC
17:28:41  *** karl[m]1 has quit IRC
17:28:41  *** igor[m] has quit IRC
17:28:41  *** jeeg[m] has quit IRC
17:28:41  *** karoline[m] has quit IRC
17:28:41  *** vanessa[m] has quit IRC
17:28:41  *** amal[m] has quit IRC
17:28:41  *** blim[m] has quit IRC
17:28:41  *** patricia[m] has quit IRC
17:28:42  *** Groud[m] has quit IRC
17:28:42  *** UncleCJ[m] has quit IRC
17:28:42  *** afdal[m] has quit IRC
17:28:42  *** twom[m] has quit IRC
17:28:42  *** olmvnec[m] has quit IRC
17:28:42  *** udo[m] has quit IRC
17:28:42  *** paulus[m] has quit IRC
17:28:42  *** hylshols7qui[m] has quit IRC
17:28:42  *** freu[m] has quit IRC
17:28:49  <frosch123> bye matrix
17:29:44  <andythenorth> oh there are gists
17:29:46  <andythenorth> ok
17:32:06  <andythenorth> frosch123: works thanks :)
17:32:29  <Eddi|zuHause> frosch123: that doesn't look right
17:32:48  <Eddi|zuHause> also, bit 3 doesn't actually seem to be set in Order::MapOldOrder()
17:33:03  <frosch123> no idea where you got that bit 3 thing from
17:33:18  <frosch123> why would a order be a bit?
17:34:36  *** ad5twoknebor[m] has joined #openttd
17:34:54  <andythenorth> hmm
17:35:08  <Eddi|zuHause> ah, andythenorth misunderstood the docs
17:35:16  <andythenorth> that happens
17:35:18  <Eddi|zuHause> yes, then frosch123 seems to be right
17:35:23  <frosch123> you are referencing each other in circles :)
17:35:37  <andythenorth> if nmlc output wasn't so fricking slow under pypy, I think Iron Horse compile would be about 23 seconds
17:35:49  <andythenorth> used to be about 1min 08 seconds
17:36:03  <frosch123> anyway, according to ottd 0.1, it should be var[8A, 0, 0x1F], but it makes no difference
17:38:41  <Eddi|zuHause> frosch123: my fault, i should have checked the actual docs, not what andy was asking.
17:39:50  <andythenorth> so what are those values in the 80+ page?
17:39:58  <andythenorth> "Bits 0..4 determine the type of the order:" implies they're bits
17:40:18  <andythenorth> I know those pages have a health warning
17:41:13  <frosch123> bits 0..4 means mask 0x1F
17:48:43  *** supermop_work has quit IRC
17:53:20  *** syr has quit IRC
17:54:07  <andythenorth> maybe it's time to put some prints in nmlc
17:55:00  <andythenorth> probably here?
17:55:27  <andythenorth> it's interesting that both Chameleon and nmlc nfo output are achingly slow with pypy
17:55:42  <andythenorth> maybe there's some string stuff that's slower with JIT
17:57:16  <Eddi|zuHause> andythenorth: you mean like ActionC?
17:57:26  <andythenorth> no, these are for timing
17:58:01  <andythenorth> nfo outpu from nmlc is roughly 5x slower under pypy compared to py3.8
17:58:05  <andythenorth> output *
17:58:13  *** syr has joined #openttd
17:58:36  <andythenorth> this eats about 30% of the huge benefit that pypy brings to parse and preprocessing
18:01:17  *** glx has joined #openttd
18:01:17  *** ChanServ sets mode: +v glx
18:11:21  <andythenorth> can't get much out of that
18:11:52  <andythenorth> total time for output stage is already printed
18:12:04  <andythenorth> instrumenting deeper inside the loop just gets a lot of tiny timings :)
18:13:06  <andythenorth> 2012, pypy is slow for file.write
18:13:07  <andythenorth>
18:13:09  <andythenorth> old though
18:16:03  * andythenorth reading about StringIO
18:17:17  *** tokai|noir has joined #openttd
18:17:17  *** ChanServ sets mode: +v tokai|noir
18:19:35  <FLHerne> andythenorth: maybe?
18:19:38  <andythenorth> seems relevant
18:19:54  <andythenorth> FLHerne: maybe :)
18:20:12  <FLHerne> andythenorth: Why are you outputting nfo anyway?
18:20:36  <andythenorth> because grfcodec can compile it in about 5s
18:20:38  <FLHerne> FIRS build just builds a grf?
18:20:44  <andythenorth> and in the common case, the sprites are unchanged
18:20:51  <andythenorth> oops backwards
18:20:58  <andythenorth> in the common case, sprites are changed, nfo isn't
18:21:02  <andythenorth> make detects that
18:21:15  <andythenorth> I get a 14 second compile, instead of 30s
18:21:35  <andythenorth> but
18:21:45  <andythenorth> this was more useful when total compile was > 1 minute
18:22:26  <andythenorth> with pypy and procedures, total compile time is coming down
18:24:11  *** tokai has quit IRC
18:24:29  * andythenorth tests
18:24:40  <andythenorth> pure nml isn't fast enough yet to drop the nfo step
18:25:10  <andythenorth> if nml could detect that the input nml was unchanged, and only re-encode the realsprites, that would be a huge saving
18:26:25  <andythenorth> well, about 8 seconds probably, on 34 seconds :P
18:26:27  <andythenorth> but enough
18:30:13  <glx> detection of change input should not be too hard (something based on timestamps)
18:30:56  <andythenorth> I am also trying to figure out if stringIO is slow
18:31:03  <andythenorth> it's reported to be, in other contexts
18:31:04  <glx> then you need to cache the tree
18:31:57  <glx> with an image store
18:35:58  <andythenorth> I hacked this and
18:37:33  <andythenorth>
18:38:00  <andythenorth> ^ that misses some fraction of the nfo, but runs in 1.3s instead of 9s
18:38:24  <andythenorth> list.join instead of StringIO
18:38:44  <andythenorth> eh, clearly I had files I shouldn't there
18:40:35  <andythenorth> cleaned it
18:42:16  <glx> creating a list of strings in place of updating a big string ?
18:42:57  <nielsm> looks like it yes
18:43:00  <nielsm> I can see why it can work
18:43:14  <glx> I can see why it's faster too :)
18:43:33  <nielsm> if pypy is intensely slow at syscalls but good at juggling internal data in loops
18:43:35  * andythenorth never knows how to do things properly :P
18:43:42  <glx> usually increasing string size means reallocating
18:43:43  <FLHerne> StringIO isn't (shouldn't be) like a big string
18:43:46  <andythenorth> I just write a lot of list concatenations
18:44:08  <FLHerne> It's just a "file" backed by a chunk of memory
18:44:14  <andythenorth> I lived in a python2.4 world for the longest time, and many things were missing :|
18:45:56  <glx> FLHerne: but the effect is the same as a big string when you must increase the size I think
18:47:13  <glx> get a bigger space in memory, move all the previous data to the new space
18:48:43  <glx> and with nfo size of andythenorth's grf that can happen often
18:50:02  <andythenorth> my horrible patch does appear to produce a compilable nfo
18:50:03  <FLHerne> glx: I still don't think thats true
18:50:08  <FLHerne> > StringIO performs better is behind the scenes it just keeps a list of all the strings that have been written to it, and only combines them when necessary. So a write operation is as simple as appending an object to a list.
18:50:11  <andythenorth> and the grf size is the same as without the patch
18:50:17  <FLHerne> ^ of course, that's for CPython
18:50:31  <FLHerne> If pypy implements it in some stupid way, that would explain the difference
18:50:42  <glx> that's a possibility
18:51:12  <andythenorth> I suspected StringIO due to the usual 'not really relevant but eh' Stack Overflow posts
18:51:13  <andythenorth>
18:51:36  <andythenorth> and
18:51:57  <andythenorth> from the last link "so I don't think there's an actual bug here, just some very bad performance in StringIO.write()."
18:52:09  <FLHerne> Why is nml using StringIO anyway, in fact?
18:52:30  <andythenorth> shrug-I-don't-know emoji :)
18:52:30  <FLHerne> The whole point is to write to an actual file, so why not just do that?
18:53:01  <FLHerne> That looks like the right bug
18:54:33  <andythenorth> anyone want to do a better version of my 'fix'? :P
18:55:06  <glx> I think it does it that way in case an error happens during output generation
18:55:36  <andythenorth> it will leave the original file untouched?
18:55:45  <glx> that too
18:56:02  <FLHerne> What else, then?
18:56:15  <FLHerne> Could solve that with write-to-tmp-and-copy
18:56:25  *** supermop_work has joined #openttd
18:56:35  <FLHerne> s/copy/rename
18:57:37  <glx> that's indeed the usual way for many tools
18:57:40  <andythenorth> my horrid patch reduces a 25s compile to 18s
18:57:50  <andythenorth> not bad
18:58:53  <floodious> now you'll never have time for tea
18:59:03  <andythenorth> I'll make time :)
18:59:08  <floodious> apologize to the mad hatter you must, yoda says
18:59:10  <glx> anyway if you don't want to use temp file you have to use an efficient memory storage
19:01:44  <andythenorth> or use a temp file :P
19:02:00  <floodious> to avoid using template functors i've created some mad bitmasking nonsense:
19:04:06  <floodious> now a matter of GUI buttons + debugging + figuring out how to pass the parameters (using the string data?)
19:06:27  <floodious> i'll probably need to use templates to get the desert edge stuff working along the edges of the floodfill, or at least a callback function pointer
19:26:34  *** Wolf01 has joined #openttd
19:44:35  *** sla_ro|master has quit IRC
19:45:39  <nielsm> ships are actually pretty good at this point (still)
19:50:38  *** elliot[m] has joined #openttd
19:50:38  *** MSavoritias[m] has joined #openttd
19:50:38  *** udo[m] has joined #openttd
19:50:39  *** Heiki[m] has joined #openttd
19:50:39  *** ookfof[m] has joined #openttd
19:50:39  *** cawal[m] has joined #openttd
19:50:39  *** jact[m] has joined #openttd
19:50:39  *** olmvnec[m] has joined #openttd
19:50:39  *** grag[m] has joined #openttd
19:50:39  *** ciet[m] has joined #openttd
19:50:39  *** natmac[m] has joined #openttd
19:50:40  *** johanna[m] has joined #openttd
19:50:40  *** lapav[m] has joined #openttd
19:50:40  *** backtu[m] has joined #openttd
19:50:40  *** paulus[m] has joined #openttd
19:50:40  *** jeeg[m] has joined #openttd
19:50:40  *** vanessa[m] has joined #openttd
19:50:40  *** pina[m] has joined #openttd
19:50:40  *** karl[m] has joined #openttd
19:50:40  *** olivier[m] has joined #openttd
19:50:40  *** patricia[m] has joined #openttd
19:50:40  *** ircer[m] has joined #openttd
19:50:40  *** yoltid[m] has joined #openttd
19:50:40  *** hylshols7qui[m] has joined #openttd
19:50:41  *** afdal[m] has joined #openttd
19:50:41  *** iarp[m] has joined #openttd
19:50:41  *** khavik[m] has joined #openttd
19:50:41  *** freu[m] has joined #openttd
19:50:41  *** natalie[m] has joined #openttd
19:50:42  *** mrtmol[m] has joined #openttd
19:50:42  *** nolep[m] has joined #openttd
19:50:42  *** twom[m] has joined #openttd
19:50:42  *** blim[m] has joined #openttd
19:50:43  *** joey[m] has joined #openttd
19:50:43  *** nartir[m] has joined #openttd
19:50:43  *** ist5shreawf[m] has joined #openttd
19:50:43  *** robert[m]1 has joined #openttd
19:50:43  *** julie[m] has joined #openttd
19:50:44  *** Corns[m] has joined #openttd
19:50:44  *** osvaldo[m] has joined #openttd
19:50:44  *** dag[m] has joined #openttd
19:50:45  *** fjodor[m] has joined #openttd
19:50:45  *** albert[m] has joined #openttd
19:50:45  *** amal[m] has joined #openttd
19:50:45  *** glothit7ok[m] has joined #openttd
19:50:45  *** igor[m] has joined #openttd
19:50:48  *** einar[m] has joined #openttd
19:50:50  *** josef[m] has joined #openttd
19:50:50  *** yur3shmukcik[m] has joined #openttd
19:50:50  *** karoline[m] has joined #openttd
19:50:50  *** josef[m]1 has joined #openttd
19:50:50  *** UncleCJ[m] has joined #openttd
19:50:50  *** dude[m]1 has joined #openttd
19:50:50  *** fiddeldibu[m] has joined #openttd
19:50:50  *** pothyurf[m] has joined #openttd
19:50:50  *** labs[m] has joined #openttd
19:50:50  *** Groud[m] has joined #openttd
19:50:50  *** buggeas40d[m] has joined #openttd
19:50:50  *** arron[m] has joined #openttd
19:51:07  <Wolf01> "Enter the Matrix"
19:51:28  <andythenorth> yum
19:57:05  <Wolf01> I wonder if I could run whatsapp on bluestacks
19:59:17  <floodious> bluestacks = android emulator?
19:59:28  <floodious> it used to be trivial with android86
20:01:14  <floodious> ~2012
20:01:28  <Wolf01> Yep
20:03:47  *** sla_ro|master has joined #openttd
20:04:36  <floodious> i think last time i failed to make it work was 2017, seems not just general compatibility but android86 is no longer supported
20:04:41  <floodious> or was... no idea anymore
20:05:10  * andythenorth saves another 100KB of nml
20:15:20  <andythenorth> are registers slow to use?
20:15:34  <andythenorth> as compared to vars
20:17:44  <floodious> if the name reflects what it is accurately, a register should operate more quickly and remain cached while vars would be best for infrequent use and often uncached... but who knows these days they might call a 28.8 modem connection a "register"
20:18:25  <floodious> play pink floyd - money
20:21:15  <frosch123> temp. registers are probably always faster than a 40+x&60+x variables
20:22:59  <frosch123> the easiest var40 requires at least a indirect function call, which is probably not noticeable. but when the var requires iterating over the consist it definitely has lost.
20:26:00  <floodious> on most systems a register is the basic unit, so it's accessed directly. the time spent executing an instruction/operation is generally proportionate to both the operation itself plus the steps taken to "dereference" the data used by the instruction
20:26:47  <floodious> so a register = 1 step, while accessing memory = 1 (set the offset), 2 (address and load the memory)
20:27:34  <nielsm> but we are not talking about a hardware machine here, we are talking about the NewGRF callback execution/resolution mechanism
20:27:45  <floodious> accessing a pointer in memory = 1 (offset), 2 (adding to any base offset), 3 (address and load), 4 (additional offsets to the loaded pointer address), 5 (addressing and loading back the data)
20:27:55  <nielsm> which is a rather unusual instruction set
20:28:13  <floodious> it'll still follow the laws of our lord turing
20:28:27  <nielsm> no because "register" means something completely different
20:28:50  <floodious> then it's not really a register and that brings to question "why the name?"
20:30:52  <frosch123> because it was modelled after a 8051-style cpu with single accumulator
20:31:09  <floodious> then it is a register, just a virtual one
20:33:10  <frosch123> i guess if you want correct terms, then "newgrf register" is a "c variable" and "newgrf variable" is a "c++ pure member function"
20:33:34  *** Wormnest__ has quit IRC
20:33:38  <floodious> pure virtual? pure?
20:34:00  <frosch123> no, "pure" as "no sideeffects"
20:34:12  <floodious> const?
20:34:23  <frosch123> yeah, probably should have said that
20:34:53  <frosch123> but that is all implementation detail
20:35:28  <floodious> mixed with "c++" throws off the meaning a bit, saying "compsci pure" i'd just be scratching my head anyway :)
20:37:10  <nielsm> if you're interested in the implementation, this is the place to start (sort-of):
20:37:37  <andythenorth> hmm another 200KB of nml removed
20:37:57  <andythenorth> does grf use some compression magic?
20:38:06  <andythenorth> or alternatively, is it really inefficient?
20:38:07  <glx> only for images
20:38:08  <frosch123> only realsprites
20:38:14  <frosch123> nfo is uncompressed
20:38:14  <nielsm> 8bpp realsprites use some run length encoding
20:38:43  <andythenorth> I have reduced nearly 2MB of nfo filesize, grf filesize is ~constant
20:39:02  <frosch123> did you remove comments and newlines?
20:39:11  <andythenorth> nah
20:39:15  <frosch123> otherwise you should have a 3:1 relation
20:39:35  <andythenorth> I looked for an nml option to drop the comments in the nfo output
20:39:37  <andythenorth> I don't need them
20:39:39  <frosch123> 2 nfo hex digits + space = 1 grf byte
20:39:57  <glx> grf is nfo + images size
20:41:26  <floodious> depending upon the compression method and format of the data, weird things can happen since packing the data with higher density can have a negative influence on high quality compression (lzw2, etc) applied afterward. so raw data passed in will beat RLE by far in most cases since the noise (data entropy) of the RLE is higher, giving the compression algorithm less to work with
20:41:57  <glx> the nfo part is uncompressed ;)
20:41:59  <floodious> i've found that in a majority of cases trying to minimize data, it's very easy to get caught with premature optimization and wreak your end result inside a packer
20:42:54  <floodious> lzma2.. not lzw :P
20:43:34  <glx> and the format is quite old so not advanced compression algo
20:44:47  <frosch123> if any manages to reduce the switch count, it will also reduce ottd's memory usage
20:45:18  <nielsm> have anyone looked at making a better VM for newgrf? :)
20:46:08  <frosch123> i added some optimiser two years ago
20:46:13  <glx> we should try to make nmlc replace return switch references with return constant if the referenced switch returns the same value for all cases
20:46:15  <andythenorth> frosch123: do you want to profile Iron Horse release and dev memory use? :P
20:46:57  <frosch123> andythenorth: i want a lot :p
20:47:15  <LordAro> frosch123: did you ask santa nicely?
20:47:18  <andythenorth> it's a common problem
20:48:05  <frosch123> LordAro: since i moved southwards, i do not longer have boots for sinterklaas
20:48:11  * andythenorth deletes another few hundred switches
20:48:29  <andythenorth> another 200KB gone
20:48:40  <floodious> replacing the VM would typically just be something like using a well established existing one, which wasn't available in a reliable way decades ago... but then portability = oops
20:48:44  <glx> just using procedures andythenorth ?
20:48:52  <andythenorth> some procedures, some global switches
20:49:03  <andythenorth> some just replacing silly code
20:49:04  *** WormnestAndroid has quit IRC
20:49:44  *** WormnestAndroid has joined #openttd
20:49:49  <andythenorth> so are we merging procedures glx? :)
20:49:58  <andythenorth> my Horse branch is diverging a lot from my master :P
20:50:17  <frosch123> hmm, i guess i'll watch sw this evening, just to be done with it forever
20:50:20  <nielsm> huh, did trf2 remove the railroad track upgrade function?
20:52:12  <LordAro> frosch123: i give it 5 years before they make another trilogy
20:52:24  <floodious> all matters of the economy
20:52:30  <floodious> if it pays, they'll do it
20:52:36  <glx> less than 5 years I bet :)
20:52:40  <frosch123> LordAro: yes, but i am fine with ignoring that one completely
20:53:09  <LordAro> heh
20:53:21  <glx> or maybe not a trilogy, just standalone films
20:53:21  <frosch123> i also quit bond after that poker movie
20:53:38  <LordAro> they got better!
20:53:53  <LordAro> well, not the next one, but the third one was good!
20:53:58  <michi_cc>
20:53:58  <floodious> i'd assume they're looking to pad their catalog for their streaming service, same as netflix has been doing the past years with a 5+ year advantage
20:54:01  <LordAro> then the next was a bit meh
20:54:09  <michi_cc> Already planned :)
20:54:12  <frosch123> LordAro: mostly i considered the character to most-non-bond ever
20:54:18  <LordAro> michi_cc: non-skywalkery trilogies don't count :p
20:55:00  <LordAro> but i think there'll be at least a bit of time before X, XI & XII
20:55:03  <glx> floodious: but disney owns its catalog, that's already an advantage
20:55:17  <floodious> mostly filled with old stuff though
20:55:28  <floodious> netflix is loaded with 2017, 2018, 2019 content
20:55:43  <floodious> i'm not sure of the numbers but glancing at it, looks near 50% netflix productions
20:55:43  <Wolf01> Meh time doesn't work without js
20:55:45  <LordAro> disney owns about 1/3 of all film productions, they're not exactly wanting
20:55:55  <floodious> depends where the demand is
20:56:44  <milek7_> 'poker movie' is casino royale?
20:56:51  <frosch123> yes
21:11:15  <Wolf01> Ok, the lego control+ app is unusable... :(
21:31:08  *** floodious has quit IRC
21:31:30  *** frosch123 has quit IRC
21:52:45  *** sla_ro|master has quit IRC
21:52:48  *** gelignite has quit IRC
22:07:24  <andythenorth> another 500KB of nml removed
22:08:19  <supermop_work> andythenorth - man of the late 80s
22:08:33  <supermop_work> fighting to save every half megabyte
22:09:06  <supermop_work> Distributing GRFs on floppies
22:09:43  <LordAro> andythenorth: what's the total so far?
22:11:16  <andythenorth> 2.9MB of nml, 2.4MB of nfo, almost no change to the grf
22:11:29  <supermop_work> only two floppies
22:12:01  <Eddi|zuHause> andythenorth: are you sure you're actually compiling the right file? :p
22:12:12  <nielsm> if you decompile the grf with grfcodec, how large is the nfo then?
22:12:16  <andythenorth> timestamp says I am Eddi|zuHause
22:12:58  <andythenorth> the decompiled nfo is 11.4MB, the nml-generated nfo is 15.8MB
22:13:23  <nielsm> do comments make up that entire difference perhaps?
22:13:33  <andythenorth> substantially yes
22:13:37  <andythenorth> nml could do with dropping them
22:13:47  <andythenorth> I suspect it would output faster also
22:13:53  <Eddi|zuHause> andythenorth: when was the last time i told you you're optimizing the wrong metric?
22:14:07  <andythenorth> earlier today
22:14:11  <nielsm> not writing 4 MB will save a bit of time probably yes
22:14:54  <andythenorth> Eddi|zuHause: it's not really about the filesize, it's about being able to delete loops that are nested 2 or 3 levels deep
22:15:00  <andythenorth> which makes for more readable templates
22:15:04  <andythenorth> the filesize is a side effect
22:28:17  * andythenorth wonders about openttd support for flipped vehicles :P
22:28:30  <andythenorth> it's maybe as much as 25% of Iron Horse code
22:28:42  <andythenorth> every spriteset is duplicated
22:29:33  <andythenorth> 12k spritesets used, could be 6k
22:30:56  <andythenorth> I'm guessing it's 10 lines or so in OpenTTD
22:31:12  <andythenorth> I just don't know what to write in the 10 lines :)
22:31:58  <andythenorth> matrix transform of the offsets
22:51:45  *** Flygon has joined #openttd
22:52:25  <Wolf01> nice mod
22:53:28  <nielsm> interesting
23:01:32  <andythenorth> sleeping time
23:04:31  *** andythenorth has left #openttd
23:04:48  *** WormnestAndroid has quit IRC
23:05:44  *** supermop_work has quit IRC
23:08:51  *** WormnestAndroid has joined #openttd
23:08:57  *** supermop_work has joined #openttd
23:23:57  *** HerzogDeXtEr has quit IRC
23:38:58  *** supermop_work has quit IRC
23:39:22  *** supermop_work has joined #openttd

Powered by YARRSTE version: svn-trunk