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 https://git.io/Je5po 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 https://git.io/Je5po 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 https://git.io/Jedfs 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 https://git.io/Jedfs 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 https://git.io/JedUN 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 https://git.io/JedTc 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 https://git.io/JedTR 11:47:59 <floodious> https://pastebin.com/JvPnSPuU 11:48:06 <floodious> floodfill c++ 11:48:18 <milek7_> maybe related: https://www.tt-forums.net/viewtopic.php?t=70846 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 https://git.io/JedTw 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> http://www.maizure.org/projects/decoded-openttd/index.html 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 https://repo.or.cz/w/openttd/fttd.git 13:56:24 <FLHerne> thread: https://www.tt-forums.net/viewtopic.php?t=58420 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> http://www.icosahedron.de/openttd/git/newmap.git <-- 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> https://imgur.com/a/Xx1aPY4 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 https://0x0.st/z0vf.png 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 http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_VehicleArray 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> https://github.com/OpenTTD/nml/pull/66 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 http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_VehicleArray 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 https://github.com/OpenTTD/OpenTTD/blob/master/src/newgrf_engine.cpp#L729 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 https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Vehicles#Modflags_.28FE_and_FF.29 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 pastebin.com 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? https://github.com/OpenTTD/nml/blob/master/nml/output_nfo.py 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> https://stackoverflow.com/questions/12584135/pypy-slow-at-writing-file 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: https://vmprof.readthedocs.io/en/latest/ maybe? 18:19:38 <andythenorth> https://bitbucket.org/pypy/pypy/issues/979 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 https://github.com/OpenTTD/nml/blob/master/nml/output_nfo.py and output_base.py 18:37:33 <andythenorth> https://github.com/andythenorth/nml/commit/400034d6bf0c5d4eea4eaca08eea3548c27a40aa 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 https://github.com/andythenorth/nml/commit/895196bd694366b089be4176994577f4d2b7d6c2 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> https://stackoverflow.com/questions/25580925/why-is-stringio-object-slower-than-real-file-object/25581107 18:51:36 <andythenorth> and https://bitbucket.org/pypy/pypy/issues/979 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: http://pastebin.com/cgyVY76Q 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) https://0x0.st/z0xk.jpg 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): https://github.com/OpenTTD/OpenTTD/blob/master/src/newgrf_spritegroup.h 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> https://time.com/5018112/new-star-wars-trilogy-rian-johnson-last-jedi/ 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> https://steamcommunity.com/sharedfiles/filedetails/?id=1941552275 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