Log for #openttd on 19th March 2017:
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:
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
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 :)
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
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>
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
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?
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>
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>
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>
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>
16:50:12  <andythenorth> achievements such
16:54:31  <LordAro> mm, 6 year old thread
17:19:54  <peter1138>
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
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
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>
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,
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

Powered by YARRSTE version: svn-trunk