Times are UTC Toggle Colours
00:00:02 <dlite> uh oh 00:00:25 <dlite> thanks 00:01:25 <ST2> guess it worked out :D 00:02:32 <dlite> you are very helpful, but I'm just left wondering that how some poor fellow who doesn't know how to connect to IRC will find out... 00:03:06 <ST2> trial / error works well most of the times xD 00:16:10 <dlite> if I take the same sets listed on that server, any advice for a start date to run an enjoyable sandbox? 00:16:54 <ST2> all depends on what you want - because FIRS have different industries among years 00:17:30 <dlite> meaning balancing jumps back and forth if I start from 1800's? 00:18:11 <ST2> never tried so early game date 00:19:09 <ST2> the earlier date we ever used was this one: https://openttd.btpro.nl/forum/28-tournaments/2668-international-workers-day-tournament 00:19:27 <ST2> and was for a specific targed, no FIRS 00:58:31 <supermop_home> I wonder if a catenary pylon sprite can be positioned in the center of a tile 01:13:23 *** FLHerne has quit IRC 02:08:34 *** FLHerne has joined #openttd 02:09:04 *** funnel has quit IRC 02:09:14 *** funnel has joined #openttd 02:53:30 *** glx has quit IRC 03:27:38 *** chomwitt has quit IRC 03:30:36 *** gelignite_ has joined #openttd 03:30:38 *** gelignite_ has quit IRC 03:38:11 *** gelignite has quit IRC 04:48:58 *** Tharbakim has quit IRC 04:53:01 *** Tharbakim has joined #openttd 05:55:09 *** HerzogDeXtEr1 has quit IRC 06:40:51 *** sim-al2 has quit IRC 06:47:53 *** Progman has joined #openttd 06:57:30 *** Supercheese has quit IRC 07:01:57 *** andythenorth has joined #openttd 07:02:55 <andythenorth> o/ 07:07:18 *** sla_ro|master has joined #openttd 08:11:29 <peter1138> yes 08:14:00 <Eddi|zuHause> supermop_home: the usual problem there is bounding boxes... you'd have to distinguish between vehicles passing in front or behind the pole 08:14:23 <Eddi|zuHause> i'd love tram tracks with pylon in the middle, though 08:16:42 *** Alberth has joined #openttd 08:16:42 *** ChanServ sets mode: +o Alberth 08:16:57 <Alberth> o/ 08:17:14 <andythenorth> moin 08:18:39 <andythenorth> so…when is a python module too big for a single file? o_O 08:19:16 <andythenorth> this one is about to cross the 1k line barrier http://dev.openttdcoop.org/projects/firs/repository/entry/src/industry.py 08:19:23 <andythenorth> 1k lines often seems ‘too many' 08:20:02 <andythenorth> but it’s so convenient having an entire encapsulated in one file :P 08:20:06 <Eddi|zuHause> andythenorth: any number you could say there will have too many exceptions to be a useful criterium 08:21:17 <Alberth> how strongly are those classes connected? 08:21:32 <andythenorth> completely 08:21:38 <andythenorth> it could be separate industry / tile 08:21:47 <andythenorth> but there would be a lot of cross-importing between both 08:23:01 <Eddi|zuHause> you could split off each class that derives from (object) into its own module (including its subclasses) 08:23:34 <andythenorth> the most obvious split is industry and tile 08:23:47 <andythenorth> as that maps to the separation in newgrf spec and in templates 08:23:48 <Alberth> it seems to have tile, sprite, and industry as 'main' objects, at a global glance 08:24:18 <Eddi|zuHause> also, deriving from (object) is not needed anymore in python3 08:24:33 <andythenorth> I should fix that 08:24:57 <Alberth> how does an industry need Tile classes? 08:25:22 <Alberth> I would say it has such objects, but you don't need to import a class for that 08:25:39 <Eddi|zuHause> also, you don't necessarily need to split the *module*, you can split the *file* and do "from subfile import A,B,C" 08:26:39 <Alberth> perhaps split the data structure creation code into a separate file instead? 08:27:42 <andythenorth> neither of you are saying “leave it alone, that file is not too long” o_O 08:27:53 <Alberth> :D 08:28:16 <Alberth> Sprite and Industry are very different things, imho 08:28:53 <Alberth> but splitting doesn't reduce total code size, it just distributes code to more files 08:29:17 <andythenorth> yup 08:29:19 <Eddi|zuHause> andythenorth: no we're not saying that, but we're not saying the opposite either. because it's a very weak argument 08:29:34 <Alberth> in the end, it's best to do what you want, rather than trying to comply with some standard 08:29:48 <andythenorth> I’ll add the new code, and see what that does 08:29:57 <andythenorth> it’s potentially long declarative stuff 08:30:21 <Eddi|zuHause> long declarative stuff usually warrants its own file 08:30:39 <andythenorth> yes 08:30:52 <Alberth> judging by the names of the classes, I would expect layering of the concepts on top of each other, rather than mutual inclusion, tbh 08:31:07 <andythenorth> I should put the declarative stuff in a template :P 08:31:11 <andythenorth> and template the python 08:31:19 <Alberth> meta-python 08:31:22 <andythenorth> code generating the code generator 08:31:27 <andythenorth> so wrong 08:31:32 <Eddi|zuHause> import compiler 08:31:32 <Alberth> nah :p 08:32:02 <Alberth> but it sounds like something is wrong, I agree :) 08:33:32 <Alberth> from your big code removal yesterday, I am starting to think something is wrong in nml 08:33:58 <Alberth> it can't be right that you have to write that much code for nml, imho 08:35:13 <Eddi|zuHause> well, CETS is like 1000 lines python, which generates 100k lines of nml 08:36:14 <andythenorth> FIRS is currently around 215k lines 08:36:15 <Alberth> wouldn't it be more logical to have 1000+ lines nml, which generates 100k lines NFO? 08:36:18 <Eddi|zuHause> however, andy's python is a tiny bit less space-efficient :p 08:36:20 <andythenorth> it was 480k lines yesterday 08:36:39 <andythenorth> yesterday a FIRS compile from clean was about 1m 40s 08:36:42 <andythenorth> today it’s 1m 08:36:54 <Alberth> given that nml is supposed to be a high level grf language? 08:36:59 <andythenorth> spritelayouts are very very very ineffecient :) 08:37:09 <andythenorth> or maybe they’re very efficient, but very time consuming 08:37:58 <Alberth> what is faster now? the nml generation, or nml itself, or...? 08:38:05 <andythenorth> nml compilation 08:38:06 <Eddi|zuHause> Alberth: well, if you think NFO as assembler, then NML is more like C than C++ or python 08:38:32 <Alberth> that sounds reasonable 08:38:41 <andythenorth> notably I only refactored 5 out of 81 industries 08:39:06 <Eddi|zuHause> the problem is that nobody ever thought of an "expression"-simplification that supercedes the switch-structure 08:39:09 <andythenorth> most of the code removal was spritelayouts for desert and snow 08:39:31 <andythenorth> the wonderful part is that these industries can’t build in desert or snow :) 08:39:38 <Alberth> Eddi|zuHause: imperative code? 08:39:44 <andythenorth> so compile has been 33% slower than it needed to be for years :P 08:39:56 <Eddi|zuHause> Alberth: yeah, something like that... minus loops 08:40:19 <Alberth> mostly "-Cleanup: delete unused code" thus, andy :) 08:40:25 <andythenorth> :P 08:40:52 <andythenorth> the perils of automated migration from a sub-optimal macro templating system :P 08:41:22 <Alberth> who knows what other gems may be hidden in there :p 08:42:11 <andythenorth> I know of a couple more 08:42:45 <Alberth> soon you can go back to your old computer :) 08:42:45 <andythenorth> ok there’s a lot of dead newlines here, but 231 lines per spritelayout :) https://paste.openttdcoop.org/phpkcrryy 08:43:02 <andythenorth> @calc 81 * 2 * 231 08:43:03 <DorpsGek> andythenorth: 37422 08:43:44 <andythenorth> @calc 81 * 2 * 209 08:43:44 <DorpsGek> andythenorth: 33858 08:43:59 <andythenorth> @calc 4000 / 200000 08:43:59 <DorpsGek> andythenorth: 0.02 08:44:06 <andythenorth> hmm 2% I can save probably 08:44:11 <andythenorth> not so big :) 08:44:33 <andythenorth> ah, no, my assumptions are all wrong 08:45:31 <andythenorth> @calc 81 * 9 * 231 08:45:31 <DorpsGek> andythenorth: 168399 08:45:41 <andythenorth> industries probably have about 9 spritelayouts on average, not 2 08:45:48 <andythenorth> so most of FIRS is spritelayouts 08:46:00 <andythenorth> @calc 81 * 9 * 209 08:46:00 <DorpsGek> andythenorth: 152361 08:46:25 <andythenorth> cutting 22 lines for snow stuff will scale up :P 08:47:48 *** Hiddenfunstuff has joined #openttd 08:49:22 <andythenorth> takes a few seconds off, not much 08:50:27 <andythenorth> and the line length is more like 285k, the 215k figure above is because my editor hadn’t finished loading it :P 08:53:47 <andythenorth> Alberth: I’m not sure how nml could be ‘less’, unless OpenTTD does more 08:55:46 <andythenorth> notably there is a lot of repetitive handling of terrain awareness because we prefer open-ended use of cbs and vars 08:56:09 <andythenorth> I can’t just declare a spriteset with a flag on it for the terrain 08:59:42 <Alberth> fair enough, I guess that also holds for nml, you can lift the primitive to something simpler, but then you loose flexibility 08:59:54 <andythenorth> I wouldn’t rule it out 09:00:02 <andythenorth> the flexibility still exists underneath 09:00:24 <Alberth> yep, keeping us stuck to CPU bound rendering :) 09:01:11 <andythenorth> comparable is that nml has keywords and even built-in functions for some things, but sometimes it’s necessary to do ‘[STORE_TEMP(${offset}, 0x10F), var[0x61, 0, 0x000000FF, 0x47]]’ 09:01:34 <andythenorth> nobody made a function for ‘get cargo in vehicle with offset x in consist’ :P 09:02:23 <Alberth> number of primitives will explode, likely 09:02:23 <andythenorth> so how would primitives free us from CPU-bound? o_O 09:03:26 <Alberth> basically, openttd has no clue what grf is doing, so it assumes you may want to check anything before you draw a sprite 09:03:44 <andythenorth> yup 09:03:58 <andythenorth> oh you mean the rendering in ottd, not the nml compile? o_O 09:04:00 <Alberth> thus, you need pretty much entire openttd data to decide rendering a single sprite 09:04:19 <Alberth> yes, rendering in-game :) 09:04:20 <andythenorth> means we can’t just dump sprites through the GPU? 09:04:55 <Alberth> you can, but unless you move entire openttd data and grf code there too, the cput must compute what graphics to draw 09:05:42 <Alberth> so the entire massive parallel GPU is basically blocked on cpu input for each triangle it draws 09:05:53 * andythenorth has brain experiment 09:06:30 <andythenorth> just taking vehicles, if we provided pre-configured vehicles directly in OpenTTD, with no newgrf cbs 09:06:38 <andythenorth> 1. the declarative format for mods would be simpler? 09:06:47 <andythenorth> 2. we could stop running cbs for vehicles? 09:07:21 <andythenorth> vehicle gets pre-defined configuration points, which resolve to static properties 09:07:28 <Alberth> sure, you throw all the flexibility out the window, things get simpler 09:07:53 <andythenorth> but as soon as I load a traditional newgrf, all benefit is lost? 09:08:58 <Alberth> "all" is a bit too much, but a lot 09:09:10 * andythenorth was thinking about, e.g. BlueFISH 09:09:14 *** funnel_ has joined #openttd 09:09:18 <andythenorth> he’s got all the sprites, and he is trying to code it now 09:09:33 <andythenorth> but really, ships are so stupid in game that there’s very little use for magic 09:09:48 <andythenorth> declarative format would be 09:09:54 <andythenorth> - sprites (ship, effects) 09:09:57 <andythenorth> - properties 09:10:02 <andythenorth> that is all :P 09:10:19 <Alberth> partial support has the problem that you duplicate functionality in code 09:10:31 <andythenorth> and there would be 2 mod formats, 2 mod compilers, 2 sets of docs 09:10:38 <andythenorth> 2 sets of confusion :P 09:10:52 <andythenorth> and a harsh learning curve from ‘simple mod’ to ‘newgrf’ 09:11:09 <Alberth> and 1.5 openttds or so 09:11:29 <Alberth> where you still haven't made the transition to gpu 09:11:35 <andythenorth> yup 09:11:44 <andythenorth> ‘mod simplicity’ could be solved with a web app, if it was a worthwhile thing to do 09:11:53 <andythenorth> and that has been discarded before as an idea 09:12:54 <Alberth> split rendering between cpu and gpu creates all kinds of duplication maintenance problems, sprite rendered from cpu slightly different from gpu, etc 09:13:23 <Alberth> and the benefit is quite questionable 09:14:18 <andythenorth> does it get me ‘full animation’ back? o_O :P 09:15:00 <Alberth> I don't know why it disappeared, tbh 09:15:19 <andythenorth> the video bandwidth explanation is plausible 09:15:21 <Alberth> likely you need a second image telling what is animated 09:15:43 <Alberth> or a sequence of images, one for each frame 09:15:58 <Alberth> both are feasible in a gpu 09:16:22 <andythenorth> replace palette cycle with frame animation? o_O 09:16:32 <andythenorth> the game could pretty much pre-compute the sprites 09:16:40 <Alberth> yep, standard solution 09:16:55 <andythenorth> it would be seamless from a sprite artist / newgrf point of view 09:17:01 <Alberth> I don't see how animation eats video bandwidth 09:17:27 <Alberth> you're still sending the same size pictures, just different ones 09:17:31 <andythenorth> oh :). iirc it was your suggestion to me as the cause 09:17:38 <andythenorth> maybe I confused who told me 09:18:02 <Alberth> obviously, it costs cpu time 09:18:25 <andythenorth> palette cycle animation seems very 1989-Nintendo 09:18:29 <Alberth> you have to find the animated pixels, find the replacement colour, and send that 09:19:00 <andythenorth> maybe I could buy a dedicated chip to do it :P 09:19:08 <Alberth> palette cycling only works if you have a palette, typically 8bpp images 09:19:27 <Alberth> old video cards do have palettes in hardware :) 09:19:40 <Alberth> saves memory :) 09:19:43 <andythenorth> in theory, isn’t it just a really simple fast transform? 09:20:01 * andythenorth wonders if we could kickstarter a dedicated chip 09:20:06 <Alberth> it is, but you have a LOT of pixels 09:20:33 <Alberth> nowadays, dedicated chip is not worth it, the gpu can do it 09:20:46 <andythenorth> I think mine doesn’t :P 09:20:59 <Alberth> it can run a computation for each pixel 09:21:04 <andythenorth> presumably we don’t use the right instructions to tell the GPU do it? 09:21:17 <Alberth> we don't render from the gpu 09:21:36 <Alberth> cpu computes the pixels, and sends the picture to the video 09:21:48 <Alberth> gpu is a single pass-through, at best 09:22:04 <andythenorth> we don’t do the palette cycle via SDL (or something else I don’t understand)? 09:22:37 <Alberth> no idea, but palette animation doesn't exist in 32bpp 09:22:42 <Alberth> there is no palette 09:22:43 <andythenorth> /* Video backend takes care of the palette animation */ 09:22:45 * andythenorth digging 09:23:01 *** tokai has joined #openttd 09:23:01 *** ChanServ sets mode: +v tokai 09:23:03 <andythenorth> there are 3 possible causes I’ve been given for this 09:24:14 <andythenorth> 1. OS X used to offload 8bpp blitting to GPU on our behalf, but Intel removed that from their GPUs 4-5 years ago and/or Apple dropped the 8bpp support 09:24:31 <andythenorth> 2. ‘modern computers don’t have much bandwidth to GPU’ 09:24:46 <andythenorth> 3. it’s a retina / HDPI issue, related to needing 4x as many pixels 09:24:55 <andythenorth> none of them are provable by me :P 09:25:54 <Alberth> gpus are by nature 32bpp 09:28:36 <Alberth> so any palette animation must be done either by having an image for each frame, or having a 2nd image to tell which pixel is animated and an image to convert time index to some new 32 bit colour 09:28:53 <Alberth> both are feasible on a gpu 09:29:07 <Alberth> (technically, at least) 09:29:49 <Alberth> At the same time, the number of relevant 8bpp applications is close to zero 09:30:02 *** tokai|noir has quit IRC 09:30:30 <Alberth> aside from those weirdos that want to run previous century software on modern hardware 09:31:38 <Alberth> so 1 is probably true, 8bpp in gpu is useless, and there are not enough applications that need palette animation to invest the effort of coding a generic gpu solution 09:32:20 <Alberth> the alternative to gpu-bound animation is cpu-bound animation, like what openttd is doing 09:32:52 <Alberth> obviously, the cpu gets very busy making all these pictures, and all that data must be sent to the video card 09:33:30 <Alberth> under the assumption that gpu does rendering, which holds for close to 100% of the applications, bandwidth between cpu and gpu isn't very relevant 09:34:08 <Alberth> you push lots of images once to the gpu, it has lots of space to store them 09:34:22 <Alberth> so this bus is an option to decrease costs 09:34:35 <andythenorth> whereas we need to push big bitmaps 20 or 30 times per second? 09:34:47 <andythenorth> and if it’s HDPI / retina, they’re 4x bigger 09:34:54 <Alberth> yes, if you do cpu bound rendering 09:35:44 <andythenorth> long way from FIRS nml to this :) 09:36:23 <Alberth> 3 is relevant in bandwidth (ie 2), but not in animation, I think 09:36:57 <Alberth> more pixels just means more work, animation itself doesn't change, as far as I can see 09:37:54 <Alberth> obviously, if you want non-blocky graphics, you need more work, and probably much more animation colours 09:37:57 <andythenorth> there’s nothing clever like only sending a diff of the bitmap? 09:38:04 <andythenorth> animation changes more :P 09:38:20 * andythenorth assumes nothing clever 09:38:28 <Alberth> so a full animation is in the end the simplest generic solution 09:38:54 <Alberth> not sure if clever tricks apply there 09:39:19 <andythenorth> doubt it 09:39:20 <Alberth> nowadays, applications just render everything, every frame 09:39:50 <Alberth> dirty rectangle administration to minimize updates are not used any more 09:40:01 <Alberth> likely related to the gpu rendering, I think 09:40:09 * andythenorth wonders how hard to replace palette animation with frames 09:40:24 <Alberth> gpu's have a few thousand processors 09:40:58 <andythenorth> ho I managed to hang up openttd by turning full animation on :) 09:41:04 <andythenorth> hasn’t died, just hung 09:41:08 <Alberth> :) 09:41:50 <Alberth> wasn't there a bug report from samu about that? 09:42:04 <andythenorth> perhaps 09:42:09 <andythenorth> frosch has been fixing the bugs there 09:42:34 <Alberth> peter threw in a few too 09:43:02 <Alberth> I haven't closely followed that 09:43:21 * andythenorth pulls 09:47:56 <andythenorth> hmm 09:48:59 <andythenorth> ‘full animation’ is *substantially* faster for me on tip, compared to 1.6.1 09:50:46 * andythenorth puts 100 RVs in the map 09:50:52 <andythenorth> still fast relative to 1.6.1 09:50:59 <andythenorth> slow compared to ‘full animation’ disabled 09:51:09 <andythenorth> could we switch blitter on ffwd? :P 10:04:42 <Alberth> like the "black window" blitter? :p 10:06:05 <andythenorth> yes 10:06:06 <andythenorth> :P 10:06:33 <andythenorth> so ‘full animation’ is much improved, but still unusable :) 10:06:35 * andythenorth tested 10:06:51 <Alberth> perhaps a newer SDL2 10:07:26 <Alberth> oh, we don't use that 10:07:34 <Alberth> newer SDL is unlikely :) 10:08:05 <andythenorth> ho, crashed it again :) 10:08:57 <andythenorth> I blame com.apple.inputmethod.EmojiFunctionRowItem 10:08:59 <Alberth> speed thing sounds like #6546 10:09:48 <Alberth> apple has a function to input omojis? 10:10:48 <andythenorth> it’s probably the emoji bar thing 10:10:57 <andythenorth> https://issues.apache.org/jira/browse/GROOVY-8058 10:11:14 <andythenorth> other projects are reporting it also 10:36:04 *** Samu has joined #openttd 10:36:07 <Samu> HI 10:38:17 *** gelignite has joined #openttd 10:42:22 <Alberth> o/ 10:42:22 *** mescalito has quit IRC 10:42:29 *** mescalito has joined #openttd 10:42:43 *** Wormnest has joined #openttd 10:46:20 *** frosch123 has joined #openttd 10:51:29 <andythenorth> quak 10:51:40 <frosch123> moi 10:51:57 <frosch123> i don't think we made any performance changes to 32bpp anim 10:52:11 <frosch123> only crashes 10:54:39 <andythenorth> I have a crash, might be OS X bug though https://paste.openttdcoop.org/pecztjz1v/teampl/raw 10:55:07 <andythenorth> similar-looking issues are being reported for other apps, when switching back to them after a period in background 10:55:42 <andythenorth> triggers when I switch ‘full animation’ after leaving OpenTTD in background, not reliably reproducible though 10:59:02 *** hugo_ has joined #openttd 11:08:10 <andythenorth> FIRS sets a *lot* of xextent, yextent, zextent 11:08:26 <andythenorth> is there any point? much of it is copy-paste, so likely wrong 11:10:59 <frosch123> xoffs=0, yoffs=0, xextent=16, yextent=16 are default 11:11:01 <frosch123> you can skip those 11:11:25 <frosch123> zoffset=0 is also default 11:12:29 <frosch123> i guess the stuff is mostly used for fences 11:14:27 <andythenorth> does zoffset do much useful? 11:14:46 <frosch123> it's for when you have bridges next to the industry 11:14:58 <frosch123> no idea what the default is 11:15:10 <frosch123> don't set it too small and don't set it too big 11:15:26 <frosch123> but the details don't matter 11:16:08 <andythenorth> given that we’re in 2D, same drawing position can be achieved with xoffs + yoffs, or zoffs? 11:16:31 <frosch123> they are not about drawing position :p 11:17:18 <frosch123> anyway, remove the stuff if it matches the default 11:17:21 <frosch123> keep it, if it does not not 11:17:34 <frosch123> it's not worth the time to break it just for changing stuff 11:18:02 <andythenorth> zoffset isn’t used anywhere afaict 11:19:18 <frosch123> it's for slope-aware stuff 11:20:04 <andythenorth> ok found it used for coast slopes 11:20:38 <andythenorth> zextent is widely used, but probably shouldn’t be 11:24:10 * andythenorth deletes it all 11:24:19 <andythenorth> possible much regret 11:33:12 *** FLHerne has joined #openttd 11:37:23 <Eddi|zuHause> zextent is for bounding boxes 11:43:39 *** FLHerne_ has joined #openttd 11:46:08 <andythenorth> ~530 zextents removed 11:46:15 <andythenorth> or rather, they’re all now 32 11:46:28 <andythenorth> possibly even that is wrong 11:46:40 <andythenorth> but now it’s one value for most of FIRS 11:51:07 *** FLHerne has quit IRC 11:54:05 *** Geth has joined #openttd 11:58:51 *** Hiddenfunstuff has quit IRC 12:01:57 <andythenorth> 19 slopes? https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Industry_Tiles#Land_info_of_nearby_tiles_.2860.29 12:02:03 * andythenorth counting on fingers :P 12:02:45 <andythenorth> 0-14 and 23, 27, 29, 30 12:03:11 <Eddi|zuHause> sounds right 12:03:49 <Eddi|zuHause> 15 doesn't exist, because it would be flat with 4 corners raised 12:03:58 <Eddi|zuHause> and the 4 steep slopes... 12:04:48 <frosch123> and the 4 halftile slopes 12:06:09 <Eddi|zuHause> you might be confusing this with foundations 12:26:18 * andythenorth making magic trees 12:30:02 <andythenorth> also slope_to_sprite_offset() magic 12:30:36 <Eddi|zuHause> there are only two approaches to magic: less magic, or more magic. 12:31:42 <andythenorth> in this case, more 12:31:49 <andythenorth> the genie is out of the bottle 12:34:13 <Samu> i achieved something 12:34:21 <Samu> about friendly river generations 12:35:11 <Samu> but it's not yet finished :( 12:37:03 <Samu> https://paste.openttdcoop.org/ppvuydn55 12:38:45 <Samu> for this part, it checks if it can build a lock when checking flowsdown 12:39:22 <Samu> however, it may still not be connected, seems that I need something else 12:39:32 <Samu> i don't know which direction the pathfinder is building the river 12:42:58 <Samu> how does it decide which tile to build next? :( 12:52:18 *** sim-al2 has joined #openttd 12:53:14 <Eddi|zuHause> better than the cat is in the bag 12:57:19 *** Progman has quit IRC 12:59:04 <Samu> http://imgur.com/apFfpRx 12:59:28 <Samu> help 12:59:42 <Samu> river isn't connected 12:59:47 *** Compu has quit IRC 13:00:13 <Samu> it checks if it can build locks, but then when the river is built, it doesn't check if it's connectable :( 13:02:13 *** HerzogDeXtEr has joined #openttd 13:04:56 *** heffer_ has quit IRC 13:06:10 *** Compu has joined #openttd 13:13:52 *** heffer has joined #openttd 13:59:05 *** maciozo has joined #openttd 14:01:23 *** chomwitt has joined #openttd 14:13:03 <andythenorth> for industries like fruit plantations, which are mostly trees 14:13:10 <andythenorth> should I allow autoslope? o_O 14:14:03 <Samu> nop 14:14:11 <andythenorth> it’s kind of neat, but doesn’t work as player might expect 14:14:24 <andythenorth> some tiles can be lowered / raised, some can't 14:26:23 *** sim-al2 has quit IRC 14:28:58 <Eddi|zuHause> it should just follow the original slope 14:33:41 <andythenorth> it does, but if I construction nearby,... 14:34:24 <andythenorth> autoslope allows player to raise or lower tile (not not all corners) 14:34:31 <andythenorth> but / not /s 14:34:31 *** maciozo has quit IRC 14:35:40 <andythenorth> deleted another 30k lines from FIRS 14:36:06 <andythenorth> construction states in spritelayout, unused by nearly all industries 14:36:09 <andythenorth> another 4s faster 14:36:51 *** maciozo has joined #openttd 14:40:32 <Eddi|zuHause> in that case, yes, that may be a good idea 14:41:35 <andythenorth> in theory it’s a good idea, but the limitations on some corners are confusing :) 14:41:38 <andythenorth> and annoying :P 14:41:56 *** Progman has joined #openttd 14:42:32 <Eddi|zuHause> i don't know the limitations 14:43:19 <Eddi|zuHause> isn't it like switch(is valid slope afterwards) {return allow/deny}? 14:45:09 <andythenorth> nah, it’s just flag on the tile 14:49:37 <andythenorth> 7 year old’s building style makes me wince :D 14:58:03 <andythenorth> saved another 2k lines by removing comments, and junk ‘if’ clauses where the condition is never met 15:21:53 *** mescalito has quit IRC 15:22:39 <andythenorth> and another 1k 15:26:56 <andythenorth> frosch123: have your nml ideas developed any further? o_O 15:27:20 * peter1138 decided to play a big game 15:27:26 <peter1138> (512x512, low towns, high water) 15:27:27 *** Samu has quit IRC 15:28:03 <peter1138> Not making a profit yet :S 15:28:46 <peter1138> Probably shouldn't've double-tracked yet. 15:31:42 *** mescalito has joined #openttd 15:33:03 <andythenorth> 512x512 is enormous 15:33:09 <peter1138> yes 15:33:16 * andythenorth would be lost :P 15:33:23 * andythenorth might be exagerating 15:33:35 <peter1138> low towns helps 15:34:00 <peter1138> only doing passengers & mail at the moment 15:47:43 <andythenorth> ha ha magic trees 15:47:57 <Eddi|zuHause> <andythenorth> 7 year old’s building style makes me wince :D <-- isn't that the "joy" of having kids? telling them they're doing great when objectively it's all terrible? 15:48:08 <andythenorth> no 15:48:21 <andythenorth> I tell them it’s awful, when objectively, they’re doing ok, age-adjusted 15:51:13 <supermop_home> what are magic trees 15:56:06 <andythenorth> slope aware tile with 4 trees positioned on it 15:56:11 <andythenorth> used for plantations, etc 15:56:26 <andythenorth> the position of the trees has to vary slightly per slope, and there are 19 slopes 15:59:02 <andythenorth> http://dev.openttdcoop.org/projects/firs/repository/revisions/c04da00a767b/diff/src/industries/orchard_piggery.py?utf8=%E2%9C%93&type=sbs 16:01:19 <dlite> is there anything that could be done for poor OSX mouse rendering performance with hiDPI display? 16:02:29 <dlite> I don't recall this being a problem when I had 1080p display, but having upgraded to 4k monitor, cursor feels quite choppy in-game now 16:07:30 <andythenorth> is the TTD cursor lagging the actual mouse? 16:08:00 <dlite> TTD cursor 16:08:13 <andythenorth> is ‘full animation’ on or off? 16:08:44 <dlite> how do I check (ie. default, installed yesterday 1.7.0-RC1) 16:09:02 <andythenorth> toolbar -> wrench icon (or gear) -> ‘full animation' 16:09:05 <andythenorth> it will be checked or not 16:09:43 <dlite> I think that makes a difference 16:09:58 <dlite> so it is related to the palette animation things discussed earlier today? 16:10:05 <andythenorth> plausibly yes 16:10:13 <andythenorth> what mac? 16:10:15 <dlite> or what was palette animation when original TTD came out... 16:10:20 <dlite> hack... 16:10:35 <andythenorth> modern chipset? 16:10:37 <dlite> quadcore ivy-bridge 3570k with radeon 7970 16:11:09 <dlite> I think everything ran nicely before I upgraded to 4K monitor, which I now run with 200% scaling 16:11:23 <andythenorth> 4K is a lot :) 16:11:27 <dlite> but that was some time ago 16:11:32 <dlite> ie. last summer or so 16:11:45 <dlite> I think I only run like 1600x900 resolution window at the moment 16:11:53 <dlite> it feels that full screen works even more poorly 16:12:31 <dlite> otoh, I booted windows yesterday evening to try there and scroll-zoom is unusable and scrolling performance way worse 16:12:38 <dlite> FPS felt higher under windows though 16:13:11 <dlite> scrollwheel under windows uses the "how many rows per mouse wheel click" from windows control panel to scale the clicks 16:13:32 <dlite> so if I have anything else than 1 set in windows control panel / logitech utility, it zooms multiple steps in game 16:14:17 <dlite> but the real problem with windows was that holding righ mouse button down and dragging to move the viewport was very slow / inconsistent motion, under OSX it works as expected, albeit low FPS 16:16:33 <andythenorth> I have same experience on OS X 16:16:41 <andythenorth> no experience on Windows :) 16:16:45 <peter1138> You've gone from a screen of 1.4 million pixels to 8.3 million pixels. Oddly enough that takes more grunt. 16:18:29 <andythenorth> peter1138: shall we go back to 640x480 :) 16:18:31 <dlite> we've also gone some 13 years since introduction of OpenTTD 0.1.x 16:18:40 <peter1138> andythenorth, fuck yeah! 16:18:55 <dlite> but don't take this as criticism, I'm happy with the game 16:42:52 <andythenorth> newgrf settings and newgrf parameters windows have started doing some weird ‘focus follows cursor’ thing 16:45:55 <Eddi|zuHause> whenever i want to scroll, i pause first 16:46:05 <Eddi|zuHause> also, when zooming out 16:48:12 <andythenorth> you should automate that in a patch :) 16:48:50 <Eddi|zuHause> not very multiplayer-safe :p 16:49:04 <andythenorth> pish-posh :P 16:50:08 <andythenorth> https://www.tt-forums.net/viewtopic.php?p=1184177#p1184177 16:50:12 <andythenorth> achievements such 16:54:31 <LordAro> mm, 6 year old thread 17:19:54 <peter1138> https://ugears.online/products/460-steam-locomotive-with-tender-mechanical-model-advanced?variant=18066227783 17:29:36 <andythenorth> bonkers 17:29:55 *** Gja has joined #openttd 17:40:32 *** Samu has joined #openttd 17:42:26 <Eddi|zuHause> andythenorth: the game has exactly one type of such "achievements": "first vehicle arrives at <station>" 17:42:45 <andythenorth> I was unconvinced 17:42:58 <andythenorth> I play casual games with achievements, but they don’t keep me playing 17:43:06 <andythenorth> they’re just visual chewing gum 17:43:37 <Eddi|zuHause> there are different types of achievements 17:44:15 <Eddi|zuHause> 1) achievements that simply track you progress through the game (finished the tutorial, reached goal <X>) 17:44:31 <Eddi|zuHause> 2) grinding achievements (do <X> 500 times) 17:45:03 <Eddi|zuHause> and 3) weird paths achievements (reach <X> in unconventional ways) 17:45:54 <Eddi|zuHause> the 3) kind is the one that is particularly interesting 17:46:13 <Eddi|zuHause> but most achievements are not of that kind 17:52:20 <andythenorth> apart from the pictures, it would be a GS :P 17:52:38 <andythenorth> lot of conditions to check for not a lot of benefit imho 17:56:46 <Eddi|zuHause> also, different kinds of achievements appeal to different people, see also https://www.youtube.com/watch?v=yxpW2ltDNow 18:30:11 *** FLHerne has joined #openttd 18:34:37 *** FLHerne_ has quit IRC 18:40:48 *** Supercheese has joined #openttd 18:40:50 *** glx has joined #openttd 18:40:50 *** ChanServ sets mode: +v glx 18:41:37 <peter1138> Hmm, infrastructure says I'm paying for canals ;( 18:41:47 <peter1138> I have docks, but no canals. 18:42:37 <supermop_home> does the water under a depot count? 18:42:49 <peter1138> Probably 18:43:05 <supermop_home> that sounds familiar to me 18:45:07 * andythenorth writes worst code ever 18:45:49 <DorpsGek> Commit by translators :: r27804 /trunk/src/lang (3 files) (2017-03-19 19:45:38 +0100 ) 18:45:50 <DorpsGek> -Update from Eints: 18:45:51 <DorpsGek> italian: 7 changes by lorenzodv 18:45:52 <DorpsGek> luxembourgish: 11 changes by Phreeze 18:45:53 <DorpsGek> french: 7 changes by glx 18:48:03 * peter1138 reboots his NAS. 18:48:10 <peter1138> NFS appears to have borked :( 18:48:23 <andythenorth> never saw a NAS that wasn’t crap 18:48:28 <andythenorth> only seen a few mind 18:48:58 <peter1138> First time it's done that in 3 years. 18:49:41 <andythenorth> the only one I used that was any good was one of these https://s-media-cache-ak0.pinimg.com/564x/4a/5d/d9/4a5dd9d89426e7f25de26f2c822d5d1e.jpg 18:51:08 <peter1138> Yay, the old CRT iMac... 18:51:34 <supermop_home> hmm broke, but its so nice and sunny out feel like I should go do something 18:51:49 <supermop_home> still lots of slush and packed snow though 18:51:50 <peter1138> Going outside doesn't cost money. 18:51:58 <peter1138> Unless you mean injured broke. 18:52:12 <supermop_home> peter1138 it is a risk factor for spending money 18:52:50 <supermop_home> never saw an orange imac to be honest 18:53:20 <supermop_home> have three rolls of film to develop 18:54:04 <andythenorth> I have been outside 18:54:14 <andythenorth> finished that now 18:55:16 <peter1138> Yeah but that's because it's evening for us. 19:11:37 <supermop_home> I've been out a few times in the morning to buy pho ingredients 19:16:57 *** drac_boy has joined #openttd 19:17:01 <drac_boy> hi again 19:51:46 *** drac_boy has left #openttd 20:01:22 *** Wormnest_ has joined #openttd 20:08:02 *** Wormnest has quit IRC 20:13:56 *** sim-al2 has joined #openttd 20:19:19 <Alberth> so much scrap metal from the ports :p 20:19:38 <Alberth> s/ports/bulk terminals/ 20:23:25 <andythenorth> Steeltown? 20:24:11 <Alberth> yes 20:24:40 <andythenorth> too much? It tends to be in demand 20:24:55 <Alberth> it's fun :) 20:25:26 <Alberth> 4 terminals produce around 800t / momth 20:25:38 <andythenorth> I found they were quite cheap to fund 20:25:52 <andythenorth> I was trying to beat Silicon Valley, so I built lots :P 20:25:58 <Alberth> haha :) 20:26:08 <andythenorth> 4 or 5 together can be served by one train 20:26:12 <andythenorth> and looks good 20:26:21 <Alberth> and of course you then get a shit-load of steel to move :) 20:27:00 <Alberth> 60t steel wagon has nice capacity :p 20:27:07 <peter1138> Relying on transfers instead of distant station parts... 20:27:14 <peter1138> Need a lot of busses 20:27:59 <supermop_home> trolley buses? 20:28:21 <andythenorth> distant-station-join always beats the bus :P 20:28:30 <andythenorth> you need tramz 20:28:46 <peter1138> Yeah, just thinking about them. 20:29:08 <peter1138> It always wins but I end up 'cheating' by building a giant station covering a whole town. 20:35:21 * peter1138 ponders revisiting multiple docks. 20:37:02 *** chomwitt1 has joined #openttd 20:37:58 *** chomwitt has quit IRC 20:39:41 *** frosch123 has quit IRC 20:41:18 <peter1138> Hmm, I guess "RoadStop" would have to be renamed 20:41:40 <peter1138> Otoh, ships didn't use anything of roadstops except a list of tiles 20:41:48 <peter1138> So maybe just a tile list would do 20:47:17 <andythenorth> RoadShips 20:47:24 <andythenorth> maybe another time :P 20:48:41 <peter1138> Well, V453000 did that "RailShips"... 20:49:03 <V453000> I iz innocent 20:53:43 <Supercheese> doesn't cirdan's branch have multiple-docks? 20:54:14 <Supercheese> https://www.tt-forums.net/viewtopic.php?f=33&t=58420 20:59:01 <andythenorth> it does, but New Map also 21:01:47 *** iSoSyS has joined #openttd 21:03:15 <peter1138> Probably too far gone 21:04:12 <Eddi|zuHause> cirdan has made it abundantly clear that he has no interest in his patches making it into trunk 21:04:34 <Eddi|zuHause> which is sad, but... 21:09:25 <peter1138> Yeha, it's not like you can just look at the repo and pick the features you want. 21:12:01 *** Alberth has left #openttd 21:13:47 <peter1138> 20:53 < Supercheese> doesn't cirdan's branch have multiple-docks? 21:13:52 <peter1138> ^ So totally irrelevant. 21:14:42 <FLHerne> Eddi|zuHause: It seems odd to complain that he's uninterested when his useful trunk-ready one is afaik still not upstream... 21:15:41 <Eddi|zuHause> FLHerne: there's not much i can do about that either 21:20:19 <Eddi|zuHause> peter1138: it's not about whether you can just go ahead and commit it, but that he won't actively support it 21:21:26 <peter1138> eh? 21:21:56 <peter1138> FLHerne, trunk-ready what? 21:22:31 <FLHerne> Airport overbuilding, https://www.tt-forums.net/viewtopic.php?f=33&t=35867 21:23:02 <FLHerne> (maybe not anymore, since he gave up and forked) 21:23:55 <peter1138> 2008. Hah 21:30:15 <peter1138> Oh well. 21:30:40 <peter1138> Here's how all our developers became developers: They hung around on IRC discussing stuff. 21:31:12 <peter1138> They also started by fixing things. 21:34:03 <peter1138> Waaaah they didn't accept my feature patch waaaah tends to just get ignored, especially after the likes of richk 21:35:05 <andythenorth> who did ‘close airports’ in the end? 21:35:09 <andythenorth> that’s a handy feature 21:36:36 <peter1138> I've never used it :p 21:37:05 <peter1138> Damn it, I can't play 6th notes with one hand and 8th notes on the other :( 21:41:38 <Eddi|zuHause> that's a skill you need to practice a lot :p 21:42:37 <Eddi|zuHause> luckily, i don't need that skill :p 21:47:09 <andythenorth> very bedtime 21:47:12 *** andythenorth has left #openttd 21:57:46 *** Progman has quit IRC 21:58:03 <DorpsGek> Commit by peter1138 :: r27805 trunk/src/ship_cmd.cpp (2017-03-19 22:57:54 +0100 ) 21:58:04 <DorpsGek> -Codechange: Remove function ShipGetNewDirectionFromTiles 21:58:05 <DorpsGek> The only user of ShipGetNewDirectionFromTiles can be better 21:58:06 <DorpsGek> served by DiagdirBetweenTiles, so remove the former. (cirdan) 21:59:33 <DorpsGek> Commit by peter1138 :: r27806 trunk/src/ship_cmd.cpp (2017-03-19 22:59:24 +0100 ) 21:59:34 <DorpsGek> -Codechange: Remove function ShipGetNewDirection 21:59:35 <DorpsGek> ShipGetNewDirection has no side effects and its return value 21:59:36 <DorpsGek> is ignored by its only caller, so do away with it. 21:59:37 <DorpsGek> Also remove now unused _new_vehicle_direction_table. (cirdan) 22:02:28 <DorpsGek> Commit by peter1138 :: r27807 trunk/src/ship_cmd.cpp (2017-03-19 23:02:20 +0100 ) 22:02:29 <DorpsGek> -Codechange: Remove _ship_leave_depot_offs 22:02:30 <DorpsGek> There is already TileOffsByDiagDir for that. (cirdan) 22:02:41 <peter1138> Can pick tiny patches though 22:30:55 <DorpsGek> Commit by peter1138 :: r27808 /trunk/src (rail.cpp track_func.h) (2017-03-19 23:30:47 +0100 ) 22:30:56 <DorpsGek> -Codechange: Adjust the size of _track_crosses_trackdirs 22:30:57 <DorpsGek> _track_crosses_trackdirs is indexed by a Track, not a 22:30:58 <DorpsGek> Trackdir, so adjust its size accordingly. (cirdan) 22:32:00 *** mr_pants has joined #openttd 22:32:45 <Samu> ohh, fixing ship pathfinding? 22:32:49 <Samu> cool 22:34:26 *** mr_pants has quit IRC 22:39:24 *** Gja has quit IRC 22:42:25 *** JezK_ has joined #openttd 22:45:06 *** Geth has quit IRC 22:49:32 <peter1138> Nah, just applying shit. 22:49:44 <peter1138> It's not exactly broken... 22:52:45 *** iSoSyS has quit IRC 22:53:36 <Samu> ships can't correctly find the closest depot 22:53:43 <Samu> have you done something about it? 22:53:52 <peter1138> Nope. 22:54:31 <peter1138> Link to fs? 22:54:34 <Samu> it needs to pathfind for the closest depot, and not the way it is doing now 22:54:50 <Samu> it locates closest depot via DistanceManhattan :( 22:55:05 <peter1138> Ship pathfinding is expensive. 22:55:06 <Samu> i don't think i reported it 22:56:14 <peter1138> Technically manhattan distance *is* the nearest. 22:56:58 <Samu> sometimes it's unreachable :( really hurts performance 22:57:11 <peter1138> Fix it! 22:57:18 *** gelignite has quit IRC 22:57:27 <Samu> I tried, but don't know how to begin 22:57:48 *** APTX has quit IRC 22:59:10 <Samu> when a bus is told to go to closest depot, it pathfinds to it, i tried to see if I could mimic the code but for ships, and i got lost, then gave up 22:59:14 *** APTX has joined #openttd 23:00:39 *** sla_ro|master has quit IRC 23:00:51 *** funnel_ has quit IRC 23:03:17 *** Wormnest_ has quit IRC 23:04:30 <peter1138> I think that just searches out in every direction and stops at the first depot. 23:04:42 <peter1138> "just" 23:04:56 <Samu> circular search? 23:05:04 <Samu> let me check 23:05:10 <peter1138> Well no, pathfinding. 23:06:18 <Samu> found it, line 141 ship_cmd.cpp 23:06:37 <peter1138> I was talking about RVs :p 23:06:52 <peter1138> There's no searching for ship depots, but you know that. 23:07:55 <peter1138> Probably similar code would work for ships but it would also be expensive. 23:08:27 <peter1138> (Although if you laid out a grid of roads, that would probably be similarly bad) 23:11:32 *** ericnoan has quit IRC 23:12:02 <glx> no because roads have only 4 directions 23:12:10 <glx> water has 8 23:13:05 <Samu> 6 23:13:31 <Samu> or, actually 12, i dunno 23:13:41 *** ericnoan has joined #openttd 23:13:48 <Samu> it's like a rail piece 23:14:14 <glx> no it's a little different than rail 23:14:45 <glx> all directions cross in the middle of water tile 23:14:45 *** mescalito has quit IRC 23:15:06 *** mescalito has joined #openttd 23:15:31 <Samu> then it's 6, in 2 directions, 12? 23:17:55 <glx> NE-SW, N-S, NW-SE, W-E in 2 directions 23:17:57 <glx> so 8 23:19:38 <Samu> N-S left, N-S right, W-E upper, W-E bottom, don't they count? 23:26:00 *** HerzogDeXtEr1 has joined #openttd 23:32:01 *** HerzogDeXtEr has quit IRC 23:32:33 <Samu> and i think road vehicles also have 12 directions~ 23:33:25 <Samu> roads* 23:34:44 <glx> I think you're right about ships (after reading the code), but roads vehicle definitely have only 4 directions because there are no diagonal roads :) 23:35:10 <Samu> they can turn 23:35:55 <Samu> coming from SW there's 3 possible exits 23:36:04 <Samu> NE, NW and SE 23:36:37 <glx> hmm right 23:37:59 <glx> road tile at worst is like a water tile, but it's very rare compared to water pathfinding