IRC logs for #openttd on OFTC at 2019-12-20
⏴ go to previous day
01: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
01:13:33 <FLHerne> Hm, now I'm not sure that's what was intended
01:50:16 <hythlodaeus> I just compiled 1.10 and i'm getting the following error when trying to run openttd
01:50:34 <hythlodaeus> Error: No available language packs (invalid versions?)
01:57:50 <hythlodaeus> nvm, forgot to do make install haha
02:09:42 *** Wormnest__ has joined #openttd
02:30:55 <glx> no need to make install, it's runable from .bin
04:24:35 *** snail_UES_ has joined #openttd
06:41:10 *** sla_ro|master has joined #openttd
08:14:12 *** andythenorth has joined #openttd
08:16:22 <andythenorth> Pikka: haz Civil?
08:17:31 <Pikka> just got to put the double track and track removal code back in ;)
08:19:27 <Pikka> it'll be done for christmas innit
08:19:28 *** tokai|noir has joined #openttd
08:19:28 *** ChanServ sets mode: +v tokai|noir
08:20:25 <andythenorth> Oof, no fish in FIRS steeltown :)
08:22:07 <andythenorth> Planes Are Broken Now And Must Be Fixed!
08:24:23 <Pikka> just remove them from the game probably
08:24:34 <Eddi|zuHause> PABNAMBF is a terrible acronym
08:25:46 <andythenorth> should I get an account on a reddit?
08:27:07 <andythenorth> all the nice chat is there now
08:27:23 <andythenorth> I particularly enjoy the reddit thing of taking a screenshot using a bad camera phone
08:27:27 <andythenorth> it's quite common
08:27:35 <Eddi|zuHause> it's social media, and all social media naturally declines from an idealistic dreamhouse to an extremist cesspool
08:28:05 <andythenorth> it's because there's no actual fighting
08:28:14 <andythenorth> IRL, this can't happen in public spaces, because fighting
08:29:18 *** D-HUND is now known as debdog
08:33:47 <andythenorth> hmm can make trigger multiple processes in a controlled way, with blocking for completion on some?
08:34:53 <andythenorth> I have two pipeline stages which run in sequence, but are completely orthogonal
08:35:41 <andythenorth> I have 8 thread units, and python will obviously only max out one of them
08:50:33 <andythenorth> that's trivially easy then :D
08:53:08 <andythenorth> hmm, output in stdout suggests that's parallelising, but total run time is only marginally faster, difference might just be noise
09:14:49 *** ChanServ sets mode: +v tokai
09:27:27 *** DorpsGek_III has joined #openttd
09:27:27 <DorpsGek_III> [OpenTTD/nml] Andrew350 opened issue #74: Speed values are slightly off when using metric units https://git.io/Je5po
09:53:27 *** andythenorth has joined #openttd
10:00:19 <Pikka> don't && when you mean &, innit
10:07:54 *** WormnestAndroid has quit IRC
10:37:03 *** WormnestAndroid has joined #openttd
10:40:40 <DorpsGek_III> [OpenTTD/nml] planetmaker commented on issue #74: Speed values are slightly off when using metric units https://git.io/Je5po
10:54:36 *** Progman has joined #openttd
11:14:48 <andythenorth> reduced iron-horse.nfo 1.2MB so far
11:14:50 <andythenorth> using procedures
11:16:00 <planetmaker> is it written in plain nfo?
11:16:31 <andythenorth> nml -> nfo -> grfcodec
11:18:20 <DorpsGek_III> [OpenTTD/nml] planetmaker opened pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD https://git.io/Jedfs
11:19:17 <andythenorth> it's faster for the common case of 'only sprites changed'
11:19:28 <andythenorth> but nmlc writes nfo *much* slower than grf
11:19:42 <planetmaker> he. As expected and asked in the original PR: regressions fail :D
11:20:00 <andythenorth> nmlc grf output is 10x faster than nfo output
11:20:15 <planetmaker> yep... 10x less to write :)
11:21:32 <andythenorth> it's interesting that pypy nmlc writes nfo 5x slower than py38 nmlc
11:21:52 * andythenorth checks that result again
11:25:08 <DorpsGek> andythenorth: 5.58823529412
11:30:23 <DorpsGek_III> [OpenTTD/nml] planetmaker updated pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD https://git.io/Jedfs
11:51:24 <andythenorth> I need a simple maths scheme, so I can resolve to numbered spritesets
11:51:47 <andythenorth> based on n vehicle variants, 2 loading states, and 2 livery options
11:52:29 <andythenorth> that would be easy to encode into bytes in a dword or something
11:52:38 <andythenorth> what about with integer maths though?
12:11:29 <peter1138> Why does my Mozilla Thunderbird keep locking up?
12:17:05 <andythenorth> is it the email client?
12:20:39 <peter1138> Also, my commute was somewhat damp today :/
12:20:54 <andythenorth> I got wetted on yesterday
12:30:12 <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD https://git.io/JedUN
12:37:11 *** floodious has joined #openttd
12: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?)
12: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?)
12:40:14 <floodious> doing this manually on a 4k x 4k is driving me nuts
12:41:03 <DorpsGek_III> [OpenTTD/nml] frosch123 commented on pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD https://git.io/JedTc
12:41:25 <Pikka> sounds like a fun project, floodious
12: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
12:42:39 <floodious> mostly gui code as usual, adding the buttons/menus to the UI
12:43:07 <LordAro> i remember a vastly improved river generator patch lurking somewhere on the forums, but nothing for manual creation
12: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 :)
12:43:36 * floodious refactors EVERYTHING
12:46:32 <DorpsGek_III> [OpenTTD/nml] frosch123 commented on pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD https://git.io/JedTR
12:49:48 <LordAro> floodious: unfortunately, the algorithm isn't the hard part :)
12: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
12:50:06 <floodious> aro; i know that :)
12:50:25 <floodious> hardest part is the damn UI, 90% of the time
12:55:44 <DorpsGek_III> [OpenTTD/nml] planetmaker commented on pull request #75: Fix ottd_display_speed to reflect changes done in OpenTTD https://git.io/JedTw
13:01:21 <floodious> ah, openttd is still in c
13:03:07 <floodious> well, there are whole c++ projects, then there are "c with classes" that evolve slowly, and openttd is the latter apparently
13:03:10 <planetmaker> it's somewhat currently being updated to c++11
13:03:23 <floodious> running into old function-based c code makes things way harder
13:03:43 <planetmaker> some parts... are simply optimized for speed
13:04:25 <floodious> well in correctly implemented c++ you should get identical machine code output, the code is just 1/10th the size
13:05:22 <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
13:06:12 <milek7_> if 'whole c++ projects' are boost-style template hell, then i rather prefer C..
13:06:24 <floodious> no, that's the opposite of proper c++ :)
13: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
13:07:31 <floodious> anyway i already said that with /me refactors everything
13:09:34 <andythenorth> nfo was 18.2MB, now 16.7MB
13:09:38 <andythenorth> procedures winning
13:09:49 <andythenorth> final grf size is unchanged, compile time barely changed
13:19:21 <planetmaker> nmlc andythenorth.nml -c -p2 -l unfinished --quiet --clear-orphaned --verbosity=4 -o andythenorth.nfo -o andythenorth.grf
14: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 ...
14: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;
14:20:00 <floodious> but re: 1/3rd, I haven't even figured out where the heck SetTileHeight() is or what it does
14:22:35 <floodious> tile_map.h inline global accessing global _m (map) [tile_index].height
14:22:46 <floodious> very oldschool c style :)
14:32:28 <LordAro> more like "barely converted from assembly" c style ;)
14:32:41 <floodious> yeah of course for those of us who know the history :)
14:45:26 <FLHerne> floodious: tbh, I don't find `SetTileHeight(tile, height)` to be particularly unreadable :P
14: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
14:49:18 <floodious> i'm cloning the repo anyway and I'll look in more detail
14:49:44 <floodious> trying to understand the overall structure of the program is quite hard, "spaghetti code" as they say
14: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
14:51:30 <planetmaker> you cannot expect to understand a 300k LOC programme in a day in-depth.
14:52:03 <floodious> i'm one of the anti-globals people
14:52:33 <floodious> anti- a lot of things, but it's not a critique just saying, i understand what makes the floodfill stuff hard
14:53:08 <floodious> nah the sourcecode helps
14: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
14:53:38 <floodious> i'm not trying to, and understanding isn't the issue
14:53:51 <floodious> i'm looking at creating a dupe and refactoring it into an OOP format
14:54:09 <FLHerne> That sounds like a very big project
14:54:28 <floodious> let's see if it happens :)
14:54:45 <FLHerne> s/day/three-month-holiday/ :P
14:55:00 <floodious> some projects i've worked on for the past 20 years
14: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
14:56:43 <floodious> problem not, but such things can be merged in across various branches
14:56:59 <floodious> anything that makes the existing code any more complex would be a waste for me
14:57:07 <FLHerne> IIRC, it doesn't make the map array non-global, but it does structure it in a much saner way
14:57:52 <planetmaker> damn... that branch has aged, too
14:57:53 <FLHerne> floodious: Despite the name, the "new features" are based on quite a comprehensive reorganization of the map structures
14:58:08 <floodious> i'll be focusing on the core/main branch
14:59:40 *** snail_UES_ has joined #openttd
15:07:27 <planetmaker> but my understanding is correct: you started with river generation and now go for entire map access refactoring? :D
15:08:08 <floodious> no, things come in layers
15: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)
15:10:51 <floodious> once i start peeling this onion though there will be tears for sure
15:45:15 *** Hythlodaeus has joined #openttd
15: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
15:46:59 <nielsm> you mean "soft" hotkeys that properly look up the configured key, right?
15:47:07 <michi_cc> Hythlodaeus: Most hotkeys can be configured (even if it's only a config file and not a GUI).
15:48:25 <Hythlodaeus> is it possible for me to pull up a script argument for that?
15:48:30 <Hythlodaeus> if so that would be lovely
15: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.
15:49:14 <nielsm> showing the key in the tooltip would need a new string formatting code
15:49:17 <Eddi|zuHause> michi_cc: iirc there's a github tag
15:49:48 <Hythlodaeus> can any of you guys add that? I doesn't sound like a lot of work
15: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)
15:50:18 <Hythlodaeus> and I would move on to add soft hotkeys to tooltips ASAP
15:50:26 <Hythlodaeus> which would be very nice IMO
15:56:50 <Hythlodaeus> just so you guys have an idea of what i am doing
15:57:14 <Hythlodaeus> standardizing instructions for all shift+ and ctrl+ shortcuts
15:57:22 <Hythlodaeus> improving descriptions
15:57:38 <Hythlodaeus> adding descriptions to tooltip that did not have them before
15:58:01 <Hythlodaeus> and I'm gonna standardize capitalization afterwards
15:58:26 <Eddi|zuHause> nielsm: looking up from the tag would be tricky, but it could just be pushed onto the text stac
16: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
16:02:24 <nielsm> though it could just be a const char *
16:02:50 <Eddi|zuHause> nielsm: some key names need to be translatable
16:03:31 *** andythenorth has joined #openttd
16: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
16:04:15 <michi_cc> String codes can have parameters, which means the hotkey code could also be encoded into the string itself.
16:04:46 *** supermop_work has joined #openttd
16:05:18 <nielsm> e.g. {CMD_HOTKEY:build_railroad} or whatever
16:05:47 <supermop_work> yo andythenorth
16:07:08 <supermop_work> pro tip: don't pick regulate for karaoke with coworkers
16:07:56 *** WormnestAndroid has quit IRC
16:08:01 *** WormnestAndroid has joined #openttd
16:08:01 <Hythlodaeus> is that the mobile TTD?
16:09:27 <Hythlodaeus> wait, regarding dynamic hotkeys
16:09:45 <Hythlodaeus> how would it present keys with longer names such as Space Bar
16:10:05 <nielsm> those will need translatable strings
16:10:19 <Hythlodaeus> preferable abbreviated
16:10:22 <nielsm> which the string formatting code will need to select
16:10:46 <Hythlodaeus> bc otherwise they would a lot of space in the tooltip window
16:11:47 <Hythlodaeus> i would suggest 4 char abbreviations
16:12:38 <floodious> "space" is fairly short, five chars
16:12:59 <floodious> "shift", "capsLK" is six
16:13:13 <Eddi|zuHause> how would you fit "Bild↑" into 4 characters?
16: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
16:13:30 <nielsm> where the new vehicle can't possibly enter the route it needs to
16:14:07 <Eddi|zuHause> Hythlodaeus: that is truely horrible
16:14:11 * floodious is a member of the anti-abbreviations organization
16:14:19 <floodious> i'm anti- a lot of stuff
16:14:36 <andythenorth> anyone see a var for 'vehicle is loading / unloading'? (or inverse )
16:14:36 <andythenorth> there's only 'unloading' which doesn't do what I want
16:14:41 <Hythlodaeus> right, 5 letters then?
16:14:55 <floodious> now you see this is ambiguous, was I previously anti-work or was it given as an example
16: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
16:15:53 <Eddi|zuHause> Hythlodaeus: it doesn't make any sense to put up an arbitrary limit to the number of letters
16: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"
16:16:28 *** WormnestAndroid has quit IRC
16:16:32 <floodious> using a unit like "em"s
16:16:41 *** WormnestAndroid has joined #openttd
16:16:56 <Hythlodaeus> point is that if you want hotkeys on tooltips you do require abbreviations
16:17:00 <nielsm> Hythlodaeus: also remember that OTTD does line breaking and can automatically widen windows to fit text
16:17:32 <Hythlodaeus> I'm aware, but there's a point where tooltip window can become too big and look ugly
16:18:00 <Hythlodaeus> and I'm already at the limit with some. i.e, the first screnshot i posted with the build signals tooltip
16:18:16 <floodious> the more general rule would be "try to aim for 4 em widths"
16:18:27 <floodious> so "MMMM" is almost == "space"
16:19:00 <Hythlodaeus> we could have two types of strings for keys tho
16:19:15 <Hythlodaeus> full name, for future GUI interface
16:19:19 <Hythlodaeus> and one abbreviated
16:21:23 <planetmaker> and "space"... is not as short in every language as in English :)
16: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
16:22:11 <Hythlodaeus> i need abbreviations for hotkey tooltips tho
16:22:13 <floodious> not to mention "space" implies rockets and the moon
16:22:42 <floodious> another option depending upon facilities is often to use "tiny font"
16:23:06 <floodious> so "space" in the same width in pixels as "spc"
16:23:21 <Hythlodaeus> wouldn't it be barely readable?
16:23:23 <floodious> that's better suited to high resolution (ppi) devices
16:23:38 <floodious> yes, the choice of "how tiny" is determined by what's minimally readable
16:23:43 <Hythlodaeus> can you post an example? I haven't seen tiny font in game yet
16:23:50 <floodious> such as a 3x5 font in pixels
16:24:04 <Eddi|zuHause> Hythlodaeus: zoom out, the town names turn to tiny font at some point
16:24:21 <nielsm> yes zoomed all the way out, all signs on the map are shown in tiny font
16: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)
16:24:27 <nielsm> the music player also uses tiny font
16:24:47 <nielsm> and the minimap legend
16:24:49 <Eddi|zuHause> the date on the newspaper is tiny font
16:25:17 <Hythlodaeus> I see, that's quite acceptable actually
16:25:35 <Hythlodaeus> I can also color it red so it pops out a bit more
16:26:39 <nielsm> don't do that, it's not necessary
16:27:10 <Hythlodaeus> would be nice tho. i like colored hotkeys, but I'll show a preview of both eventually so you can pick
16:27:14 <nielsm> if you have MS Office installed, you can turn on hotkeys in its tooltips somewhere, use that as a reference
16:27:26 <Eddi|zuHause> i'd say the opposite, the hotkey should be more shaded than the regular text
16:27:34 <floodious> they often use bold+tiny, but at low res that's not possible
16: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
16:28:37 <floodious> or use a brighter/high contrast color in place of bold
16:28:54 <Eddi|zuHause> we don't have any concept of boldness
16:29:14 <Hythlodaeus> Eddi|zuHause: thank sounds like we're all cowards here
16:30:08 <andythenorth> no loading/unloading var then? :)
16: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?
16:31:04 <Hythlodaeus> and if so, do you think a solution by the end of next week would be feasible?
16:32:07 * andythenorth doesn't trust 80+ vars
16:35:48 <planetmaker> this NewGRF update turned out somewhat larger...
16:35:52 *** HerzogDeXtEr has joined #openttd
16:35:59 <planetmaker> 693MiB download...
16:47:37 * andythenorth wonders if this could be merged?
16:47:42 <andythenorth> checks failed eh
16:48:00 <andythenorth> I have an increasingly large Iron Horse branch that depends on it
16:48:59 *** lpx is now known as Guest12040
16: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
17:01:09 *** Wormnest__ has joined #openttd
17: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
17: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
17:21:51 <nielsm> floodious: we are talking about a different game here :) transport fever 2
17:22:17 * andythenorth wonders where to find var 0A in ottd src
17:22:17 <nielsm> unless you happen to work at urban games, of course
17:22:47 * andythenorth really wants to delete a confusing spritegroup and specify spritesets directly
17: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
17:23:48 <Eddi|zuHause> floodious: i don't see how that has anything to do with the issue
17:24:07 <floodious> you'd have to locate the bug in the code to
17:24:21 <andythenorth> how is loading/unloading an actual order state?
17:24:38 <floodious> it's saved somewhere and associated with an object, that's called state
17:25:11 <nielsm> floodious it has nothing to do with that at all though, depots in trf2 are not bound to lines or vehicles
17: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
17:25:23 <Eddi|zuHause> andythenorth: we have that, but it cannot distinguish between loading and unloading phase of the order
17:25:23 <nielsm> (unless the vehicle is assigned to the depot, in which case it is not on a line)
17: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
17:25:47 <andythenorth> Eddi|zuHause: I just want anything that distinguishes between load / unload and 'everything else'
17:26:08 <andythenorth> this is just to open / close doors on trains
17:26:15 <Eddi|zuHause> floodious: you're talking absolute nonsense
17:26:47 <andythenorth> I can open / close doors with spritegroups, but they are adding boilerplate that I'm trying to delete
17:26:59 <andythenorth> and confusingly nml syntax is 'loaded' for 'not loading / unloading'
17:27:01 <Eddi|zuHause> andythenorth: then the spriteset has you covered, it has different sprites for loading (=at station) and loaded (=everywhere else)
17: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
17:27:24 <Eddi|zuHause> andythenorth: no action2 stuff needed
17:27:46 <andythenorth> I know, I just want to use action 23
17: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
17:28:12 <floodious> either way a bug if the intent is duplication of behavior
17: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
17: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
17:29:22 <floodious> you mean the problem of behavior being different?
17: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
17:29:53 <Eddi|zuHause> floodious: or the problem of not understanding what the problem is?
17:30:18 <floodious> nah, it may be that the issue is the hard state doesn't include the depot or route at all
17:30:34 <Eddi|zuHause> right, you're going on my ignore list. bye
17:30:34 <floodious> so it's impossible to duplicate, due to being a part of runtime state
17: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
17:31:30 <Eddi|zuHause> nielsm: which would be pointless, as that depot might not even exist anymore at the time of cloning
17:31:32 <nielsm> that's what I have been explaining the entire time
17: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)
17:32:10 <Eddi|zuHause> but i think pathfinding to (station+platform) instead of just (station) would probably solve the issue
17: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
17: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
17:33:30 *** gelignite has joined #openttd
17:33:32 * andythenorth wonders what the spritegroup checks
17:33:59 <Eddi|zuHause> andythenorth: it checks for OT_LOADING, probably
17:34:11 <Eddi|zuHause> (name might be different)
17:34:26 * andythenorth trying to find where action 2 is defined in src
17:34:47 <Eddi|zuHause> andythenorth: newgrf_train.cpp probably
17:35:02 <andythenorth> looks like maybe newgrf_spritegroup.cpp
17:35:12 <Eddi|zuHause> andythenorth: that's probably too generic for you
17:36:10 <andythenorth> I already looked through newgrf_engine.cpp couldn't see it
17:36:26 <andythenorth> bool in_motion = !v->First()->current_order.IsType(OT_LOADING);
17:36:51 <andythenorth> so the confusing terminology originates there :)
17:37:04 <andythenorth> assumes that 'loaded' is a synonym for 'in motion'
17:37:25 <Eddi|zuHause> "confusing terminology" is likely inherited from TTD or patch
17:37:53 <andythenorth> so I think this is var 0A bit 3
17:38:06 <andythenorth> but I'm not sure if that covers all cases
17:38:54 <andythenorth> enum OrderType : byte { looks relevant
17:39:58 <andythenorth> ok, so nml var[0x8A, ??, 0x??]
17:40:10 <andythenorth> I need bit 3, it's a word
17:40:21 <Eddi|zuHause> var[0x8A, 3, 1] probably
17:40:45 <Eddi|zuHause> value should be 0/1
17:45:54 <andythenorth> seems to work thanks :D
17:50:47 <andythenorth> wow spritegroups in nml scale horribly
17:50:57 <andythenorth> I've removed 2 spritegroups (repeated many times though)
17:51:06 <andythenorth> saves ~600KB from a 9MB nml file
17:59:23 *** frosch123 has joined #openttd
18:01:26 *** sla_ro|master has joined #openttd
18:05:21 <andythenorth> hmm, I was mistaken, this doesn't work var[0x8A, 3, 1]
18:05:36 <andythenorth> do I need to mask it or something?
18:06:25 <frosch123> 3 and 1 are already the mask
18:07:13 <andythenorth> so that should get me bit 3 of 80+ 0A?
18:07:33 <frosch123> wtf are you doing with orders?
18:07:42 <andythenorth> eliminating spritegroup use
18:08:09 <andythenorth> spritegroup defines 'loaded' as not OT_LOADING
18: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
18:08:49 <frosch123> you can also use spritegroups as procedures
18:09:08 <andythenorth> that's interesting
18:09:10 <frosch123> at least in nfo, not sure whether nml is more strict
18:09:45 <andythenorth> so could I get that to just yield 0 / 1?
18:10:06 <andythenorth> I just need to open some doors when loading / unloading :P
18:10:17 <andythenorth> it shouldn't take 600KB of nml to do that :)
18: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
18:11:22 <frosch123> does "loaded: return 1; loading: return 0 ;" work?
18:11:37 <frosch123> nielsm: no, nfo does not allow that
18:12:04 <frosch123> except in places where registers are allowed, but then nml also supports it
18:13:24 <andythenorth> nmlc ERROR: "generated/iron-horse.nml", line 1267: Expected a sprite set reference
18:13:42 <frosch123> so we need to patch nml :)
18:14:10 <andythenorth> PR 66 again? o_O
18:14:50 <frosch123> no, it's not related to procedures
18:15:23 <andythenorth> I need to chain to a second switch to check % load
18:15:28 <andythenorth> so that doors close when full
18:16:04 <frosch123> well, in theory "loading: return 0, return 1, return 2;" :)
18:16:27 <Eddi|zuHause> andythenorth: not sure why this added complexity would help anything
18:16:28 <frosch123> but yes, the "return" with "," sequence is weird
18:16:34 <andythenorth> nmlc dislikes 'return' btw
18:17:01 <andythenorth> Eddi|zuHause: it's adding nothing except smaller input file and my code is easier to read
18:17:15 <andythenorth> the resulting grf filesize is stubbornly unchanged
18:17:22 <Eddi|zuHause> andythenorth: on the possible cost of runtime performance?
18:17:25 <andythenorth> and the improved compile speed could just be variation
18:17:34 <floodious> a spritegroup is like an array of handles/references to sprites, right? so it allows you to index into the group
18:17:47 <floodious> but why would such a thing add such a significant size to the result
18:17:51 <planetmaker> my_sprite_set[loading] ?
18:17:52 <andythenorth> Eddi|zuHause: same var though? the spritegroup doesn't have any obvious caching
18:18:06 <andythenorth> runtime effect is negligible / none?
18:18:29 <Eddi|zuHause> andythenorth: i have no profiling data, but i expect action2 to be slower
18:19:14 <andythenorth> I also remain curious why var[0x8A, 3, 1] isn't working as expected
18:19:33 <andythenorth> far as I can tell it's returning 0 at all times
18:22:19 * andythenorth tries PARENT instead of SELF
18:26:09 <Eddi|zuHause> andythenorth: it definitely has to be PARENT
18:27:17 <frosch123> andythenorth: where did you get the 3 and 1 from?
18:27:54 <andythenorth> oh pastebin.com is broken, and I am banned from coop pastebin for abuse
18:28:18 <frosch123> you need var[0x8A, 0, 0xF] == 3
18:28:40 *** MSavoritias[m] has quit IRC
18:28:40 *** yur3shmukcik[m] has quit IRC
18:28:40 *** ad5twoknebor[m] has quit IRC
18:28:41 *** ist5shreawf[m] has quit IRC
18:28:42 *** hylshols7qui[m] has quit IRC
18:29:44 <andythenorth> oh there are gists
18:32:06 <andythenorth> frosch123: works thanks :)
18:32:29 <Eddi|zuHause> frosch123: that doesn't look right
18:32:48 <Eddi|zuHause> also, bit 3 doesn't actually seem to be set in Order::MapOldOrder()
18:33:03 <frosch123> no idea where you got that bit 3 thing from
18:33:18 <frosch123> why would a order be a bit?
18:34:36 *** ad5twoknebor[m] has joined #openttd
18:35:08 <Eddi|zuHause> ah, andythenorth misunderstood the docs
18:35:18 <Eddi|zuHause> yes, then frosch123 seems to be right
18:35:23 <frosch123> you are referencing each other in circles :)
18:35:38 <andythenorth> if nmlc output wasn't so fricking slow under pypy, I think Iron Horse compile would be about 23 seconds
18:35:49 <andythenorth> used to be about 1min 08 seconds
18:36:03 <frosch123> anyway, according to ottd 0.1, it should be var[8A, 0, 0x1F], but it makes no difference
18:38:41 <Eddi|zuHause> frosch123: my fault, i should have checked the actual docs, not what andy was asking.
18:39:50 <andythenorth> so what are those values in the 80+ page?
18:39:58 <andythenorth> "Bits 0..4 determine the type of the order:" implies they're bits
18:40:18 <andythenorth> I know those pages have a health warning
18:41:13 <frosch123> bits 0..4 means mask 0x1F
18:54:07 <andythenorth> maybe it's time to put some prints in nmlc
18:55:27 <andythenorth> it's interesting that both Chameleon and nmlc nfo output are achingly slow with pypy
18:55:42 <andythenorth> maybe there's some string stuff that's slower with JIT
18:57:16 <Eddi|zuHause> andythenorth: you mean like ActionC?
18:57:26 <andythenorth> no, these are for timing
18:58:01 <andythenorth> nfo outpu from nmlc is roughly 5x slower under pypy compared to py3.8
18:58:36 <andythenorth> this eats about 30% of the huge benefit that pypy brings to parse and preprocessing
19:11:21 <andythenorth> can't get much out of that
19:11:52 <andythenorth> total time for output stage is already printed
19:12:04 <andythenorth> instrumenting deeper inside the loop just gets a lot of tiny timings :)
19:13:06 <andythenorth> 2012, pypy is slow for file.write
19:16:03 * andythenorth reading about StringIO
19:17:17 *** tokai|noir has joined #openttd
19:17:17 *** ChanServ sets mode: +v tokai|noir
19:19:54 <andythenorth> FLHerne: maybe :)
19:20:12 <FLHerne> andythenorth: Why are you outputting nfo anyway?
19:20:36 <andythenorth> because grfcodec can compile it in about 5s
19:20:38 <FLHerne> FIRS build just builds a grf?
19:20:44 <andythenorth> and in the common case, the sprites are unchanged
19:20:58 <andythenorth> in the common case, sprites are changed, nfo isn't
19:21:02 <andythenorth> make detects that
19:21:15 <andythenorth> I get a 14 second compile, instead of 30s
19:21:45 <andythenorth> this was more useful when total compile was > 1 minute
19:22:26 <andythenorth> with pypy and procedures, total compile time is coming down
19:24:40 <andythenorth> pure nml isn't fast enough yet to drop the nfo step
19: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
19:26:25 <andythenorth> well, about 8 seconds probably, on 34 seconds :P
19:30:13 <glx> detection of change input should not be too hard (something based on timestamps)
19:30:56 <andythenorth> I am also trying to figure out if stringIO is slow
19:31:03 <andythenorth> it's reported to be, in other contexts
19:31:04 <glx> then you need to cache the tree
19:38:00 <andythenorth> ^ that misses some fraction of the nfo, but runs in 1.3s instead of 9s
19:38:24 <andythenorth> list.join instead of StringIO
19:38:44 <andythenorth> eh, clearly I had files I shouldn't there
19:42:16 <glx> creating a list of strings in place of updating a big string ?
19:43:00 <nielsm> I can see why it can work
19:43:14 <glx> I can see why it's faster too :)
19:43:33 <nielsm> if pypy is intensely slow at syscalls but good at juggling internal data in loops
19:43:35 * andythenorth never knows how to do things properly :P
19:43:42 <glx> usually increasing string size means reallocating
19:43:43 <FLHerne> StringIO isn't (shouldn't be) like a big string
19:43:46 <andythenorth> I just write a lot of list concatenations
19:44:08 <FLHerne> It's just a "file" backed by a chunk of memory
19:44:14 <andythenorth> I lived in a python2.4 world for the longest time, and many things were missing :|
19:45:56 <glx> FLHerne: but the effect is the same as a big string when you must increase the size I think
19:47:13 <glx> get a bigger space in memory, move all the previous data to the new space
19:48:43 <glx> and with nfo size of andythenorth's grf that can happen often
19:50:02 <andythenorth> my horrible patch does appear to produce a compilable nfo
19:50:03 <FLHerne> glx: I still don't think thats true
19: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.
19:50:11 <andythenorth> and the grf size is the same as without the patch
19:50:17 <FLHerne> ^ of course, that's for CPython
19:50:31 <FLHerne> If pypy implements it in some stupid way, that would explain the difference
19:51:12 <andythenorth> I suspected StringIO due to the usual 'not really relevant but eh' Stack Overflow posts
19: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()."
19:52:09 <FLHerne> Why is nml using StringIO anyway, in fact?
19:52:30 <andythenorth> shrug-I-don't-know emoji :)
19:52:30 <FLHerne> The whole point is to write to an actual file, so why not just do that?
19:53:01 <FLHerne> That looks like the right bug
19:54:33 <andythenorth> anyone want to do a better version of my 'fix'? :P
19:55:06 <glx> I think it does it that way in case an error happens during output generation
19:55:36 <andythenorth> it will leave the original file untouched?
19:56:15 <FLHerne> Could solve that with write-to-tmp-and-copy
19:56:25 *** supermop_work has joined #openttd
19:57:37 <glx> that's indeed the usual way for many tools
19:57:40 <andythenorth> my horrid patch reduces a 25s compile to 18s
19:58:53 <floodious> now you'll never have time for tea
19:59:03 <andythenorth> I'll make time :)
19:59:08 <floodious> apologize to the mad hatter you must, yoda says
19:59:10 <glx> anyway if you don't want to use temp file you have to use an efficient memory storage
20:01:44 <andythenorth> or use a temp file :P
20:04:06 <floodious> now a matter of GUI buttons + debugging + figuring out how to pass the parameters (using the string data?)
20: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
20:50:38 *** elliot[m] has joined #openttd
20:50:38 *** MSavoritias[m] has joined #openttd
20:50:39 *** Heiki[m] has joined #openttd
20:50:39 *** ookfof[m] has joined #openttd
20:50:39 *** cawal[m] has joined #openttd
20:50:39 *** jact[m] has joined #openttd
20:50:39 *** olmvnec[m] has joined #openttd
20:50:39 *** grag[m] has joined #openttd
20:50:39 *** ciet[m] has joined #openttd
20:50:39 *** natmac[m] has joined #openttd
20:50:40 *** johanna[m] has joined #openttd
20:50:40 *** lapav[m] has joined #openttd
20:50:40 *** backtu[m] has joined #openttd
20:50:40 *** paulus[m] has joined #openttd
20:50:40 *** jeeg[m] has joined #openttd
20:50:40 *** vanessa[m] has joined #openttd
20:50:40 *** pina[m] has joined #openttd
20:50:40 *** karl[m] has joined #openttd
20:50:40 *** olivier[m] has joined #openttd
20:50:40 *** patricia[m] has joined #openttd
20:50:40 *** ircer[m] has joined #openttd
20:50:40 *** yoltid[m] has joined #openttd
20:50:40 *** hylshols7qui[m] has joined #openttd
20:50:41 *** afdal[m] has joined #openttd
20:50:41 *** iarp[m] has joined #openttd
20:50:41 *** khavik[m] has joined #openttd
20:50:41 *** natalie[m] has joined #openttd
20:50:41 *** freu[m] has joined #openttd
20:50:42 *** mrtmol[m] has joined #openttd
20:50:42 *** nolep[m] has joined #openttd
20:50:42 *** twom[m] has joined #openttd
20:50:42 *** blim[m] has joined #openttd
20:50:43 *** joey[m] has joined #openttd
20:50:43 *** nartir[m] has joined #openttd
20:50:43 *** ist5shreawf[m] has joined #openttd
20:50:43 *** robert[m]1 has joined #openttd
20:50:44 *** julie[m] has joined #openttd
20:50:44 *** Corns[m] has joined #openttd
20:50:44 *** osvaldo[m] has joined #openttd
20:50:45 *** fjodor[m] has joined #openttd
20:50:45 *** albert[m] has joined #openttd
20:50:45 *** amal[m] has joined #openttd
20:50:45 *** glothit7ok[m] has joined #openttd
20:50:45 *** igor[m] has joined #openttd
20:50:46 *** josef[m]1 has joined #openttd
20:50:50 *** josef[m] has joined #openttd
20:50:50 *** yur3shmukcik[m] has joined #openttd
20:50:50 *** karoline[m] has joined #openttd
20:50:50 *** UncleCJ[m] has joined #openttd
20:50:50 *** einar[m] has joined #openttd
20:50:50 *** dude[m]1 has joined #openttd
20:50:50 *** fiddeldibu[m] has joined #openttd
20:50:50 *** pothyurf[m] has joined #openttd
20:50:50 *** labs[m] has joined #openttd
20:50:50 *** Groud[m] has joined #openttd
20:50:50 *** buggeas40d[m] has joined #openttd
20:50:50 *** arron[m] has joined #openttd
20:57:05 <Wolf01> I wonder if I could run whatsapp on bluestacks
20:59:17 <floodious> bluestacks = android emulator?
20:59:28 <floodious> it used to be trivial with android86
21:03:47 *** sla_ro|master has joined #openttd
21: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
21:04:41 <floodious> or was... no idea anymore
21:05:10 * andythenorth saves another 100KB of nml
21:15:20 <andythenorth> are registers slow to use?
21:15:34 <andythenorth> as compared to vars
21: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"
21:18:25 <floodious> play pink floyd - money
21:21:15 <frosch123> temp. registers are probably always faster than a 40+x&60+x variables
21: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.
21: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
21:26:47 <floodious> so a register = 1 step, while accessing memory = 1 (set the offset), 2 (address and load the memory)
21:27:34 <nielsm> but we are not talking about a hardware machine here, we are talking about the NewGRF callback execution/resolution mechanism
21: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)
21:27:55 <nielsm> which is a rather unusual instruction set
21:28:13 <floodious> it'll still follow the laws of our lord turing
21:28:27 <nielsm> no because "register" means something completely different
21:28:50 <floodious> then it's not really a register and that brings to question "why the name?"
21:30:52 <frosch123> because it was modelled after a 8051-style cpu with single accumulator
21:31:09 <floodious> then it is a register, just a virtual one
21: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"
21:33:38 <floodious> pure virtual? pure?
21:34:00 <frosch123> no, "pure" as "no sideeffects"
21:34:23 <frosch123> yeah, probably should have said that
21:34:53 <frosch123> but that is all implementation detail
21:35:28 <floodious> mixed with "c++" throws off the meaning a bit, saying "compsci pure" i'd just be scratching my head anyway :)
21:37:37 <andythenorth> hmm another 200KB of nml removed
21:37:57 <andythenorth> does grf use some compression magic?
21:38:06 <andythenorth> or alternatively, is it really inefficient?
21:38:14 <frosch123> nfo is uncompressed
21:38:14 <nielsm> 8bpp realsprites use some run length encoding
21:38:43 <andythenorth> I have reduced nearly 2MB of nfo filesize, grf filesize is ~constant
21:39:02 <frosch123> did you remove comments and newlines?
21:39:15 <frosch123> otherwise you should have a 3:1 relation
21:39:35 <andythenorth> I looked for an nml option to drop the comments in the nfo output
21:39:37 <andythenorth> I don't need them
21:39:39 <frosch123> 2 nfo hex digits + space = 1 grf byte
21: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
21:41:57 <glx> the nfo part is uncompressed ;)
21: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
21:43:34 <glx> and the format is quite old so not advanced compression algo
21:44:47 <frosch123> if any manages to reduce the switch count, it will also reduce ottd's memory usage
21:45:18 <nielsm> have anyone looked at making a better VM for newgrf? :)
21:46:08 <frosch123> i added some optimiser two years ago
21: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
21:46:15 <andythenorth> frosch123: do you want to profile Iron Horse release and dev memory use? :P
21:46:57 <frosch123> andythenorth: i want a lot :p
21:47:15 <LordAro> frosch123: did you ask santa nicely?
21:47:18 <andythenorth> it's a common problem
21:48:05 <frosch123> LordAro: since i moved southwards, i do not longer have boots for sinterklaas
21:48:11 * andythenorth deletes another few hundred switches
21:48:29 <andythenorth> another 200KB gone
21: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
21:48:44 <glx> just using procedures andythenorth ?
21:48:52 <andythenorth> some procedures, some global switches
21:49:03 <andythenorth> some just replacing silly code
21:49:04 *** WormnestAndroid has quit IRC
21:49:44 *** WormnestAndroid has joined #openttd
21:49:49 <andythenorth> so are we merging procedures glx? :)
21:49:58 <andythenorth> my Horse branch is diverging a lot from my master :P
21:50:17 <frosch123> hmm, i guess i'll watch sw this evening, just to be done with it forever
21:50:20 <nielsm> huh, did trf2 remove the railroad track upgrade function?
21:52:12 <LordAro> frosch123: i give it 5 years before they make another trilogy
21:52:24 <floodious> all matters of the economy
21:52:30 <floodious> if it pays, they'll do it
21:52:37 <glx> less than 5 years I bet :)
21:52:40 <frosch123> LordAro: yes, but i am fine with ignoring that one completely
21:53:21 <glx> or maybe not a trilogy, just standalone films
21:53:21 <frosch123> i also quit bond after that poker movie
21:53:53 <LordAro> well, not the next one, but the third one was good!
21: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
21:54:01 <LordAro> then the next was a bit meh
21:54:12 <frosch123> LordAro: mostly i considered the character to most-non-bond ever
21:54:18 <LordAro> michi_cc: non-skywalkery trilogies don't count :p
21:55:00 <LordAro> but i think there'll be at least a bit of time before X, XI & XII
21:55:03 <glx> floodious: but disney owns its catalog, that's already an advantage
21:55:17 <floodious> mostly filled with old stuff though
21:55:28 <floodious> netflix is loaded with 2017, 2018, 2019 content
21:55:43 <floodious> i'm not sure of the numbers but glancing at it, looks near 50% netflix productions
21:55:43 <Wolf01> Meh time doesn't work without js
21:55:45 <LordAro> disney owns about 1/3 of all film productions, they're not exactly wanting
21:55:55 <floodious> depends where the demand is
21:56:44 <milek7_> 'poker movie' is casino royale?
22:11:15 <Wolf01> Ok, the lego control+ app is unusable... :(
23:07:24 <andythenorth> another 500KB of nml removed
23:08:19 <supermop_work> andythenorth - man of the late 80s
23:08:33 <supermop_work> fighting to save every half megabyte
23:09:06 <supermop_work> Distributing GRFs on floppies
23:09:43 <LordAro> andythenorth: what's the total so far?
23:11:16 <andythenorth> 2.9MB of nml, 2.4MB of nfo, almost no change to the grf
23:11:29 <supermop_work> only two floppies
23:12:01 <Eddi|zuHause> andythenorth: are you sure you're actually compiling the right file? :p
23:12:12 <nielsm> if you decompile the grf with grfcodec, how large is the nfo then?
23:12:16 <andythenorth> timestamp says I am Eddi|zuHause
23:12:58 <andythenorth> the decompiled nfo is 11.4MB, the nml-generated nfo is 15.8MB
23:13:23 <nielsm> do comments make up that entire difference perhaps?
23:13:33 <andythenorth> substantially yes
23:13:37 <andythenorth> nml could do with dropping them
23:13:47 <andythenorth> I suspect it would output faster also
23:13:53 <Eddi|zuHause> andythenorth: when was the last time i told you you're optimizing the wrong metric?
23:14:11 <nielsm> not writing 4 MB will save a bit of time probably yes
23: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
23:15:00 <andythenorth> which makes for more readable templates
23:15:04 <andythenorth> the filesize is a side effect
23:28:17 * andythenorth wonders about openttd support for flipped vehicles :P
23:28:30 <andythenorth> it's maybe as much as 25% of Iron Horse code
23:28:42 <andythenorth> every spriteset is duplicated
23:29:33 <andythenorth> 12k spritesets used, could be 6k
23:30:56 <andythenorth> I'm guessing it's 10 lines or so in OpenTTD
23:31:12 <andythenorth> I just don't know what to write in the 10 lines :)
23:31:58 <andythenorth> matrix transform of the offsets
continue to next day ⏵
