IRC logs for #openttd on OFTC at 2017-03-19
⏴ go to previous day
00:14:24 <peter1138> Damn, cities make so many passengers...
00:14:41 <peter1138> 1250 passengers waiting in 1921 ;(
00:25:10 *** HerzogDeXtEr1 has joined #openttd
00:35:23 <dlite> any quick suggestions on train / vehicle sets I should get if I want to try FIRS economics?
00:35:53 <dlite> FIRS 2.0 more specifically?
00:36:44 <ST2> if you like planes, try AV8 or something ^^
00:36:58 <ST2> I'm not a planes person :)
00:37:50 *** sim-al2 has joined #openttd
00:40:55 <dlite> ST2: thanks, let me have a look
00:41:26 <ST2> well, those are actually runing on a server so, they work xD
00:42:05 <ST2> ofc, newgrf's we use are always kinda minimalistic - only what's needed :)
00:51:07 <dlite> I'm trying to read the tt-forums threads for these sets, for example the Iron Horse thread. How do I know that this set actually works and covers all the needs for FIRS2.0 cargo requirements? I mean it says: "Compatible with all known cargos", but does that really mean what it says?
00:51:36 <dlite> (I've never played with FIRS ever"
00:51:47 <supermop_home> Well I guess you have to trust Andythenorth not to lie to you
00:51:55 <ST2> well, you can try them live - server of the link above
00:52:12 <supermop_home> but most newer sets will work together
00:52:52 <supermop_home> also as andy is the creator of both Firs and Iron Horse, it is safe to assume they work together
00:53:38 <ST2> and road hog works good to :)
00:54:06 <ST2> well, prepare yourself to waste more time choosing vehicles xD
00:54:58 <supermop_home> while there are times I prefer other grfs, I generally find you can always have a pretty satisfying game with all Andy Newgrfs - they are also balanced to each other
00:55:26 <ST2> [23:51:37] <dlite> (I've never played with FIRS ever" <<-- this says that you will notice a higher learning stage :D
00:56:31 <ST2> when you decide to have YETI dudes around... prepare to scavange newgrf's for it - but the ones used with FIRS 2 usually work too :)
01: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...
01:03:06 <ST2> trial / error works well most of the times xD
01:16:10 <dlite> if I take the same sets listed on that server, any advice for a start date to run an enjoyable sandbox?
01:16:54 <ST2> all depends on what you want - because FIRS have different industries among years
01:17:30 <dlite> meaning balancing jumps back and forth if I start from 1800's?
01:18:11 <ST2> never tried so early game date
01:19:27 <ST2> and was for a specific targed, no FIRS
01:58:31 <supermop_home> I wonder if a catenary pylon sprite can be positioned in the center of a tile
03:08:34 *** FLHerne has joined #openttd
04:30:36 *** gelignite_ has joined #openttd
05:53:01 *** Tharbakim has joined #openttd
07:47:52 *** Progman has joined #openttd
08:01:57 *** andythenorth has joined #openttd
08:07:18 *** sla_ro|master has joined #openttd
09: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
09:14:23 <Eddi|zuHause> i'd love tram tracks with pylon in the middle, though
09:16:42 *** Alberth has joined #openttd
09:16:42 *** ChanServ sets mode: +o Alberth
09:18:39 <andythenorth> so…when is a python module too big for a single file? o_O
09:19:23 <andythenorth> 1k lines often seems ‘too many'
09:20:02 <andythenorth> but it’s so convenient having an entire encapsulated in one file :P
09:20:06 <Eddi|zuHause> andythenorth: any number you could say there will have too many exceptions to be a useful criterium
09:21:17 <Alberth> how strongly are those classes connected?
09:21:38 <andythenorth> it could be separate industry / tile
09:21:47 <andythenorth> but there would be a lot of cross-importing between both
09:23:01 <Eddi|zuHause> you could split off each class that derives from (object) into its own module (including its subclasses)
09:23:34 <andythenorth> the most obvious split is industry and tile
09:23:47 <andythenorth> as that maps to the separation in newgrf spec and in templates
09:23:48 <Alberth> it seems to have tile, sprite, and industry as 'main' objects, at a global glance
09:24:18 <Eddi|zuHause> also, deriving from (object) is not needed anymore in python3
09:24:33 <andythenorth> I should fix that
09:24:57 <Alberth> how does an industry need Tile classes?
09:25:22 <Alberth> I would say it has such objects, but you don't need to import a class for that
09:25:38 <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"
09:26:39 <Alberth> perhaps split the data structure creation code into a separate file instead?
09:27:42 <andythenorth> neither of you are saying “leave it alone, that file is not too long” o_O
09:28:16 <Alberth> Sprite and Industry are very different things, imho
09:28:53 <Alberth> but splitting doesn't reduce total code size, it just distributes code to more files
09: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
09:29:34 <Alberth> in the end, it's best to do what you want, rather than trying to comply with some standard
09:29:48 <andythenorth> I’ll add the new code, and see what that does
09:29:57 <andythenorth> it’s potentially long declarative stuff
09:30:21 <Eddi|zuHause> long declarative stuff usually warrants its own file
09: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
09:31:07 <andythenorth> I should put the declarative stuff in a template :P
09:31:11 <andythenorth> and template the python
09:31:22 <andythenorth> code generating the code generator
09:32:02 <Alberth> but it sounds like something is wrong, I agree :)
09:33:32 <Alberth> from your big code removal yesterday, I am starting to think something is wrong in nml
09:33:58 <Alberth> it can't be right that you have to write that much code for nml, imho
09:35:13 <Eddi|zuHause> well, CETS is like 1000 lines python, which generates 100k lines of nml
09:36:14 <andythenorth> FIRS is currently around 215k lines
09:36:15 <Alberth> wouldn't it be more logical to have 1000+ lines nml, which generates 100k lines NFO?
09:36:18 <Eddi|zuHause> however, andy's python is a tiny bit less space-efficient :p
09:36:20 <andythenorth> it was 480k lines yesterday
09:36:39 <andythenorth> yesterday a FIRS compile from clean was about 1m 40s
09:36:54 <Alberth> given that nml is supposed to be a high level grf language?
09:36:59 <andythenorth> spritelayouts are very very very ineffecient :)
09:37:09 <andythenorth> or maybe they’re very efficient, but very time consuming
09:37:58 <Alberth> what is faster now? the nml generation, or nml itself, or...?
09:38:06 <Eddi|zuHause> Alberth: well, if you think NFO as assembler, then NML is more like C than C++ or python
09:38:32 <Alberth> that sounds reasonable
09:38:41 <andythenorth> notably I only refactored 5 out of 81 industries
09:39:06 <Eddi|zuHause> the problem is that nobody ever thought of an "expression"-simplification that supercedes the switch-structure
09:39:09 <andythenorth> most of the code removal was spritelayouts for desert and snow
09:39:31 <andythenorth> the wonderful part is that these industries can’t build in desert or snow :)
09:39:38 <Alberth> Eddi|zuHause: imperative code?
09:39:44 <andythenorth> so compile has been 33% slower than it needed to be for years :P
09:39:56 <Eddi|zuHause> Alberth: yeah, something like that... minus loops
09:40:19 <Alberth> mostly "-Cleanup: delete unused code" thus, andy :)
09:40:52 <andythenorth> the perils of automated migration from a sub-optimal macro templating system :P
09:41:22 <Alberth> who knows what other gems may be hidden in there :p
09:42:11 <andythenorth> I know of a couple more
09:42:45 <Alberth> soon you can go back to your old computer :)
09:43:02 <andythenorth> @calc 81 * 2 * 231
09:43:44 <andythenorth> @calc 81 * 2 * 209
09:43:59 <andythenorth> @calc 4000 / 200000
09:44:06 <andythenorth> hmm 2% I can save probably
09:44:33 <andythenorth> ah, no, my assumptions are all wrong
09:45:30 <andythenorth> @calc 81 * 9 * 231
09:45:30 <DorpsGek> andythenorth: 168399
09:45:41 <andythenorth> industries probably have about 9 spritelayouts on average, not 2
09:45:47 <andythenorth> so most of FIRS is spritelayouts
09:46:00 <andythenorth> @calc 81 * 9 * 209
09:46:00 <DorpsGek> andythenorth: 152361
09:46:25 <andythenorth> cutting 22 lines for snow stuff will scale up :P
09:47:48 *** Hiddenfunstuff has joined #openttd
09:49:22 <andythenorth> takes a few seconds off, not much
09: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
09:53:47 <andythenorth> Alberth: I’m not sure how nml could be ‘less’, unless OpenTTD does more
09:55:46 <andythenorth> notably there is a lot of repetitive handling of terrain awareness because we prefer open-ended use of cbs and vars
09:56:08 <andythenorth> I can’t just declare a spriteset with a flag on it for the terrain
09: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
09:59:54 <andythenorth> I wouldn’t rule it out
10:00:02 <andythenorth> the flexibility still exists underneath
10:00:24 <Alberth> yep, keeping us stuck to CPU bound rendering :)
10: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]]’
10:01:34 <andythenorth> nobody made a function for ‘get cargo in vehicle with offset x in consist’ :P
10:02:23 <Alberth> number of primitives will explode, likely
10:02:23 <andythenorth> so how would primitives free us from CPU-bound? o_O
10: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
10:03:58 <andythenorth> oh you mean the rendering in ottd, not the nml compile? o_O
10:04:00 <Alberth> thus, you need pretty much entire openttd data to decide rendering a single sprite
10:04:19 <Alberth> yes, rendering in-game :)
10:04:20 <andythenorth> means we can’t just dump sprites through the GPU?
10: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
10:05:42 <Alberth> so the entire massive parallel GPU is basically blocked on cpu input for each triangle it draws
10:05:53 * andythenorth has brain experiment
10:06:30 <andythenorth> just taking vehicles, if we provided pre-configured vehicles directly in OpenTTD, with no newgrf cbs
10:06:38 <andythenorth> 1. the declarative format for mods would be simpler?
10:06:47 <andythenorth> 2. we could stop running cbs for vehicles?
10:07:21 <andythenorth> vehicle gets pre-defined configuration points, which resolve to static properties
10:07:28 <Alberth> sure, you throw all the flexibility out the window, things get simpler
10:07:53 <andythenorth> but as soon as I load a traditional newgrf, all benefit is lost?
10:08:58 <Alberth> "all" is a bit too much, but a lot
10:09:10 * andythenorth was thinking about, e.g. BlueFISH
10:09:14 *** funnel_ has joined #openttd
10:09:18 <andythenorth> he’s got all the sprites, and he is trying to code it now
10:09:33 <andythenorth> but really, ships are so stupid in game that there’s very little use for magic
10:09:48 <andythenorth> declarative format would be
10:09:54 <andythenorth> - sprites (ship, effects)
10:10:19 <Alberth> partial support has the problem that you duplicate functionality in code
10:10:31 <andythenorth> and there would be 2 mod formats, 2 mod compilers, 2 sets of docs
10:10:38 <andythenorth> 2 sets of confusion :P
10:10:52 <andythenorth> and a harsh learning curve from ‘simple mod’ to ‘newgrf’
10:11:09 <Alberth> and 1.5 openttds or so
10:11:29 <Alberth> where you still haven't made the transition to gpu
10:11:44 <andythenorth> ‘mod simplicity’ could be solved with a web app, if it was a worthwhile thing to do
10:11:53 <andythenorth> and that has been discarded before as an idea
10: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
10:13:23 <Alberth> and the benefit is quite questionable
10:14:18 <andythenorth> does it get me ‘full animation’ back? o_O :P
10:15:00 <Alberth> I don't know why it disappeared, tbh
10:15:19 <andythenorth> the video bandwidth explanation is plausible
10:15:21 <Alberth> likely you need a second image telling what is animated
10:15:43 <Alberth> or a sequence of images, one for each frame
10:15:58 <Alberth> both are feasible in a gpu
10:16:22 <andythenorth> replace palette cycle with frame animation? o_O
10:16:31 <andythenorth> the game could pretty much pre-compute the sprites
10:16:40 <Alberth> yep, standard solution
10:16:55 <andythenorth> it would be seamless from a sprite artist / newgrf point of view
10:17:01 <Alberth> I don't see how animation eats video bandwidth
10:17:27 <Alberth> you're still sending the same size pictures, just different ones
10:17:31 <andythenorth> oh :). iirc it was your suggestion to me as the cause
10:17:38 <andythenorth> maybe I confused who told me
10:18:02 <Alberth> obviously, it costs cpu time
10:18:25 <andythenorth> palette cycle animation seems very 1989-Nintendo
10:18:29 <Alberth> you have to find the animated pixels, find the replacement colour, and send that
10:19:00 <andythenorth> maybe I could buy a dedicated chip to do it :P
10:19:08 <Alberth> palette cycling only works if you have a palette, typically 8bpp images
10:19:27 <Alberth> old video cards do have palettes in hardware :)
10:19:43 <andythenorth> in theory, isn’t it just a really simple fast transform?
10:20:01 * andythenorth wonders if we could kickstarter a dedicated chip
10:20:06 <Alberth> it is, but you have a LOT of pixels
10:20:33 <Alberth> nowadays, dedicated chip is not worth it, the gpu can do it
10:20:46 <andythenorth> I think mine doesn’t :P
10:20:59 <Alberth> it can run a computation for each pixel
10:21:04 <andythenorth> presumably we don’t use the right instructions to tell the GPU do it?
10:21:17 <Alberth> we don't render from the gpu
10:21:36 <Alberth> cpu computes the pixels, and sends the picture to the video
10:21:48 <Alberth> gpu is a single pass-through, at best
10:22:04 <andythenorth> we don’t do the palette cycle via SDL (or something else I don’t understand)?
10:22:37 <Alberth> no idea, but palette animation doesn't exist in 32bpp
10:22:43 <andythenorth> /* Video backend takes care of the palette animation */
10:23:01 *** ChanServ sets mode: +v tokai
10:23:03 <andythenorth> there are 3 possible causes I’ve been given for this
10: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
10:24:31 <andythenorth> 2. ‘modern computers don’t have much bandwidth to GPU’
10:24:46 <andythenorth> 3. it’s a retina / HDPI issue, related to needing 4x as many pixels
10:24:55 <andythenorth> none of them are provable by me :P
10:25:54 <Alberth> gpus are by nature 32bpp
10: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
10:28:53 <Alberth> both are feasible on a gpu
10:29:07 <Alberth> (technically, at least)
10:29:49 <Alberth> At the same time, the number of relevant 8bpp applications is close to zero
10:30:30 <Alberth> aside from those weirdos that want to run previous century software on modern hardware
10: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
10:32:20 <Alberth> the alternative to gpu-bound animation is cpu-bound animation, like what openttd is doing
10:32:52 <Alberth> obviously, the cpu gets very busy making all these pictures, and all that data must be sent to the video card
10: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
10:34:08 <Alberth> you push lots of images once to the gpu, it has lots of space to store them
10:34:22 <Alberth> so this bus is an option to decrease costs
10:34:35 <andythenorth> whereas we need to push big bitmaps 20 or 30 times per second?
10:34:47 <andythenorth> and if it’s HDPI / retina, they’re 4x bigger
10:34:54 <Alberth> yes, if you do cpu bound rendering
10:35:44 <andythenorth> long way from FIRS nml to this :)
10:36:23 <Alberth> 3 is relevant in bandwidth (ie 2), but not in animation, I think
10:36:57 <Alberth> more pixels just means more work, animation itself doesn't change, as far as I can see
10:37:54 <Alberth> obviously, if you want non-blocky graphics, you need more work, and probably much more animation colours
10:37:57 <andythenorth> there’s nothing clever like only sending a diff of the bitmap?
10:38:04 <andythenorth> animation changes more :P
10:38:19 * andythenorth assumes nothing clever
10:38:27 <Alberth> so a full animation is in the end the simplest generic solution
10:38:54 <Alberth> not sure if clever tricks apply there
10:39:20 <Alberth> nowadays, applications just render everything, every frame
10:39:50 <Alberth> dirty rectangle administration to minimize updates are not used any more
10:40:01 <Alberth> likely related to the gpu rendering, I think
10:40:09 * andythenorth wonders how hard to replace palette animation with frames
10:40:24 <Alberth> gpu's have a few thousand processors
10:40:58 <andythenorth> ho I managed to hang up openttd by turning full animation on :)
10:41:04 <andythenorth> hasn’t died, just hung
10:41:50 <Alberth> wasn't there a bug report from samu about that?
10:42:09 <andythenorth> frosch has been fixing the bugs there
10:42:34 <Alberth> peter threw in a few too
10:43:02 <Alberth> I haven't closely followed that
10:48:59 <andythenorth> ‘full animation’ is *substantially* faster for me on tip, compared to 1.6.1
10:50:46 * andythenorth puts 100 RVs in the map
10:50:52 <andythenorth> still fast relative to 1.6.1
10:50:59 <andythenorth> slow compared to ‘full animation’ disabled
10:51:09 <andythenorth> could we switch blitter on ffwd? :P
11:04:42 <Alberth> like the "black window" blitter? :p
11:06:33 <andythenorth> so ‘full animation’ is much improved, but still unusable :)
11:07:26 <Alberth> oh, we don't use that
11:07:34 <Alberth> newer SDL is unlikely :)
11:08:05 <andythenorth> ho, crashed it again :)
11:08:57 <andythenorth> I blame com.apple.inputmethod.EmojiFunctionRowItem
11:08:59 <Alberth> speed thing sounds like #6546
11:09:47 <Alberth> apple has a function to input omojis?
11:10:48 <andythenorth> it’s probably the emoji bar thing
11:11:14 <andythenorth> other projects are reporting it also
11:38:17 *** gelignite has joined #openttd
11:42:29 *** mescalito has joined #openttd
11:42:43 *** Wormnest has joined #openttd
11:46:20 *** frosch123 has joined #openttd
11:51:57 <frosch123> i don't think we made any performance changes to 32bpp anim
11:55:07 <andythenorth> similar-looking issues are being reported for other apps, when switching back to them after a period in background
11:55:42 <andythenorth> triggers when I switch ‘full animation’ after leaving OpenTTD in background, not reliably reproducible though
12:08:10 <andythenorth> FIRS sets a *lot* of xextent, yextent, zextent
12:08:26 <andythenorth> is there any point? much of it is copy-paste, so likely wrong
12:10:59 <frosch123> xoffs=0, yoffs=0, xextent=16, yextent=16 are default
12:11:25 <frosch123> zoffset=0 is also default
12:12:28 <frosch123> i guess the stuff is mostly used for fences
12:14:27 <andythenorth> does zoffset do much useful?
12:14:46 <frosch123> it's for when you have bridges next to the industry
12:14:58 <frosch123> no idea what the default is
12:15:10 <frosch123> don't set it too small and don't set it too big
12:15:26 <frosch123> but the details don't matter
12:16:08 <andythenorth> given that we’re in 2D, same drawing position can be achieved with xoffs + yoffs, or zoffs?
12:16:31 <frosch123> they are not about drawing position :p
12:17:18 <frosch123> anyway, remove the stuff if it matches the default
12:17:21 <frosch123> keep it, if it does not not
12:17:34 <frosch123> it's not worth the time to break it just for changing stuff
12:18:02 <andythenorth> zoffset isn’t used anywhere afaict
12:19:18 <frosch123> it's for slope-aware stuff
12:20:04 <andythenorth> ok found it used for coast slopes
12:20:38 <andythenorth> zextent is widely used, but probably shouldn’t be
12:24:19 <andythenorth> possible much regret
12:33:12 *** FLHerne has joined #openttd
12:37:23 <Eddi|zuHause> zextent is for bounding boxes
12:43:39 *** FLHerne_ has joined #openttd
12:46:08 <andythenorth> ~530 zextents removed
12:46:15 <andythenorth> or rather, they’re all now 32
12:46:28 <andythenorth> possibly even that is wrong
12:46:40 <andythenorth> but now it’s one value for most of FIRS
12:58:51 *** Hiddenfunstuff has quit IRC
13:02:03 * andythenorth counting on fingers :P
13:02:45 <andythenorth> 0-14 and 23, 27, 29, 30
13:03:49 <Eddi|zuHause> 15 doesn't exist, because it would be flat with 4 corners raised
13:03:58 <Eddi|zuHause> and the 4 steep slopes...
13:04:47 <frosch123> and the 4 halftile slopes
13:06:09 <Eddi|zuHause> you might be confusing this with foundations
13:26:18 * andythenorth making magic trees
13:30:02 <andythenorth> also slope_to_sprite_offset() magic
13:30:36 <Eddi|zuHause> there are only two approaches to magic: less magic, or more magic.
13:31:42 <andythenorth> in this case, more
13:31:49 <andythenorth> the genie is out of the bottle
13:34:21 <Samu> about friendly river generations
13:35:11 <Samu> but it's not yet finished :(
13:38:45 <Samu> for this part, it checks if it can build a lock when checking flowsdown
13:39:22 <Samu> however, it may still not be connected, seems that I need something else
13:39:32 <Samu> i don't know which direction the pathfinder is building the river
13:42:58 <Samu> how does it decide which tile to build next? :(
13:52:18 *** sim-al2 has joined #openttd
13:53:14 <Eddi|zuHause> better than the cat is in the bag
14:00:12 <Samu> it checks if it can build locks, but then when the river is built, it doesn't check if it's connectable :(
14:02:13 *** HerzogDeXtEr has joined #openttd
14:59:05 *** maciozo has joined #openttd
15:01:23 *** chomwitt has joined #openttd
15:13:03 <andythenorth> for industries like fruit plantations, which are mostly trees
15:13:09 <andythenorth> should I allow autoslope? o_O
15:14:11 <andythenorth> it’s kind of neat, but doesn’t work as player might expect
15:14:24 <andythenorth> some tiles can be lowered / raised, some can't
15:28:58 <Eddi|zuHause> it should just follow the original slope
15:33:41 <andythenorth> it does, but if I construction nearby,...
15:34:24 <andythenorth> autoslope allows player to raise or lower tile (not not all corners)
15:35:40 <andythenorth> deleted another 30k lines from FIRS
15:36:06 <andythenorth> construction states in spritelayout, unused by nearly all industries
15:36:09 <andythenorth> another 4s faster
15:36:51 *** maciozo has joined #openttd
15:40:32 <Eddi|zuHause> in that case, yes, that may be a good idea
15:41:35 <andythenorth> in theory it’s a good idea, but the limitations on some corners are confusing :)
15:41:56 *** Progman has joined #openttd
15:42:32 <Eddi|zuHause> i don't know the limitations
15:43:19 <Eddi|zuHause> isn't it like switch(is valid slope afterwards) {return allow/deny}?
15:45:09 <andythenorth> nah, it’s just flag on the tile
15:49:37 <andythenorth> 7 year old’s building style makes me wince :D
15:58:03 <andythenorth> saved another 2k lines by removing comments, and junk ‘if’ clauses where the condition is never met
16:26:56 <andythenorth> frosch123: have your nml ideas developed any further? o_O
16:27:20 * peter1138 decided to play a big game
16:27:26 <peter1138> (512x512, low towns, high water)
16:28:03 <peter1138> Not making a profit yet :S
16:28:46 <peter1138> Probably shouldn't've double-tracked yet.
16:31:42 *** mescalito has joined #openttd
16:33:03 <andythenorth> 512x512 is enormous
16:33:16 * andythenorth would be lost :P
16:33:23 * andythenorth might be exagerating
16:34:00 <peter1138> only doing passengers & mail at the moment
16:47:43 <andythenorth> ha ha magic trees
16: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?
16:48:21 <andythenorth> I tell them it’s awful, when objectively, they’re doing ok, age-adjusted
16:51:13 <supermop_home> what are magic trees
16:56:06 <andythenorth> slope aware tile with 4 trees positioned on it
16:56:11 <andythenorth> used for plantations, etc
16:56:26 <andythenorth> the position of the trees has to vary slightly per slope, and there are 19 slopes
17:01:19 <dlite> is there anything that could be done for poor OSX mouse rendering performance with hiDPI display?
17: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
17:07:30 <andythenorth> is the TTD cursor lagging the actual mouse?
17:08:13 <andythenorth> is ‘full animation’ on or off?
17:08:44 <dlite> how do I check (ie. default, installed yesterday 1.7.0-RC1)
17:09:02 <andythenorth> toolbar -> wrench icon (or gear) -> ‘full animation'
17:09:05 <andythenorth> it will be checked or not
17:09:43 <dlite> I think that makes a difference
17:09:58 <dlite> so it is related to the palette animation things discussed earlier today?
17:10:15 <dlite> or what was palette animation when original TTD came out...
17:10:37 <dlite> quadcore ivy-bridge 3570k with radeon 7970
17:11:08 <dlite> I think everything ran nicely before I upgraded to 4K monitor, which I now run with 200% scaling
17:11:27 <dlite> but that was some time ago
17:11:45 <dlite> I think I only run like 1600x900 resolution window at the moment
17:11:52 <dlite> it feels that full screen works even more poorly
17:12:31 <dlite> otoh, I booted windows yesterday evening to try there and scroll-zoom is unusable and scrolling performance way worse
17:12:38 <dlite> FPS felt higher under windows though
17:13:11 <dlite> scrollwheel under windows uses the "how many rows per mouse wheel click" from windows control panel to scale the clicks
17:13:32 <dlite> so if I have anything else than 1 set in windows control panel / logitech utility, it zooms multiple steps in game
17: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
17:16:33 <andythenorth> I have same experience on OS X
17:16:41 <andythenorth> no experience on Windows :)
17: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.
17:18:29 <andythenorth> peter1138: shall we go back to 640x480 :)
17:18:31 <dlite> we've also gone some 13 years since introduction of OpenTTD 0.1.x
17:18:40 <peter1138> andythenorth, fuck yeah!
17:18:55 <dlite> but don't take this as criticism, I'm happy with the game
17:42:52 <andythenorth> newgrf settings and newgrf parameters windows have started doing some weird ‘focus follows cursor’ thing
17:45:55 <Eddi|zuHause> whenever i want to scroll, i pause first
17:46:05 <Eddi|zuHause> also, when zooming out
17:48:12 <andythenorth> you should automate that in a patch :)
17:48:50 <Eddi|zuHause> not very multiplayer-safe :p
17:50:12 <andythenorth> achievements such
17:54:31 <LordAro> mm, 6 year old thread
18:42:26 <Eddi|zuHause> andythenorth: the game has exactly one type of such "achievements": "first vehicle arrives at <station>"
18:42:45 <andythenorth> I was unconvinced
18:42:58 <andythenorth> I play casual games with achievements, but they don’t keep me playing
18:43:06 <andythenorth> they’re just visual chewing gum
18:43:37 <Eddi|zuHause> there are different types of achievements
18:44:15 <Eddi|zuHause> 1) achievements that simply track you progress through the game (finished the tutorial, reached goal <X>)
18:44:31 <Eddi|zuHause> 2) grinding achievements (do <X> 500 times)
18:45:03 <Eddi|zuHause> and 3) weird paths achievements (reach <X> in unconventional ways)
18:45:54 <Eddi|zuHause> the 3) kind is the one that is particularly interesting
18:46:13 <Eddi|zuHause> but most achievements are not of that kind
18:52:19 <andythenorth> apart from the pictures, it would be a GS :P
18:52:38 <andythenorth> lot of conditions to check for not a lot of benefit imho
19:30:11 *** FLHerne has joined #openttd
19:40:48 *** Supercheese has joined #openttd
19:41:37 <peter1138> Hmm, infrastructure says I'm paying for canals ;(
19:41:47 <peter1138> I have docks, but no canals.
19:42:37 <supermop_home> does the water under a depot count?
19:43:05 <supermop_home> that sounds familiar to me
19:45:07 * andythenorth writes worst code ever
19:45:49 <DorpsGek> Commit by translators :: r27804 /trunk/src/lang (3 files) (2017-03-19 19:45:38 +0100 )
19:45:51 <DorpsGek> italian: 7 changes by lorenzodv
19:45:52 <DorpsGek> luxembourgish: 11 changes by Phreeze
19:45:53 <DorpsGek> french: 7 changes by glx
19:48:10 <peter1138> NFS appears to have borked :(
19:48:23 <andythenorth> never saw a NAS that wasn’t crap
19:48:28 <andythenorth> only seen a few mind
19:48:58 <peter1138> First time it's done that in 3 years.
19:51:08 <peter1138> Yay, the old CRT iMac...
19:51:34 <supermop_home> hmm broke, but its so nice and sunny out feel like I should go do something
19:51:49 <supermop_home> still lots of slush and packed snow though
19:51:50 <peter1138> Going outside doesn't cost money.
19:51:58 <peter1138> Unless you mean injured broke.
19:52:12 <supermop_home> peter1138 it is a risk factor for spending money
19:52:50 <supermop_home> never saw an orange imac to be honest
19:53:20 <supermop_home> have three rolls of film to develop
19:54:04 <andythenorth> I have been outside
19:54:14 <andythenorth> finished that now
19:55:16 <peter1138> Yeah but that's because it's evening for us.
20:11:37 <supermop_home> I've been out a few times in the morning to buy pho ingredients
20:16:57 *** drac_boy has joined #openttd
21:01:22 *** Wormnest_ has joined #openttd
21:13:56 *** sim-al2 has joined #openttd
21:19:19 <Alberth> so much scrap metal from the ports :p
21:19:38 <Alberth> s/ports/bulk terminals/
21:24:40 <andythenorth> too much? It tends to be in demand
21:25:26 <Alberth> 4 terminals produce around 800t / momth
21:25:38 <andythenorth> I found they were quite cheap to fund
21:25:52 <andythenorth> I was trying to beat Silicon Valley, so I built lots :P
21:26:08 <andythenorth> 4 or 5 together can be served by one train
21:26:21 <Alberth> and of course you then get a shit-load of steel to move :)
21:27:00 <Alberth> 60t steel wagon has nice capacity :p
21:27:07 <peter1138> Relying on transfers instead of distant station parts...
21:27:14 <peter1138> Need a lot of busses
21:28:21 <andythenorth> distant-station-join always beats the bus :P
21:28:46 <peter1138> Yeah, just thinking about them.
21:29:08 <peter1138> It always wins but I end up 'cheating' by building a giant station covering a whole town.
21:35:21 * peter1138 ponders revisiting multiple docks.
21:37:02 *** chomwitt1 has joined #openttd
21:41:18 <peter1138> Hmm, I guess "RoadStop" would have to be renamed
21:41:40 <peter1138> Otoh, ships didn't use anything of roadstops except a list of tiles
21:41:48 <peter1138> So maybe just a tile list would do
21:47:24 <andythenorth> maybe another time :P
21:48:41 <peter1138> Well, V453000 did that "RailShips"...
21:53:43 <Supercheese> doesn't cirdan's branch have multiple-docks?
21:59:01 <andythenorth> it does, but New Map also
22:03:15 <peter1138> Probably too far gone
22:04:12 <Eddi|zuHause> cirdan has made it abundantly clear that he has no interest in his patches making it into trunk
22:04:34 <Eddi|zuHause> which is sad, but...
22:09:25 <peter1138> Yeha, it's not like you can just look at the repo and pick the features you want.
22:13:47 <peter1138> 20:53 < Supercheese> doesn't cirdan's branch have multiple-docks?
22:13:52 <peter1138> ^ So totally irrelevant.
22: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...
22:15:41 <Eddi|zuHause> FLHerne: there's not much i can do about that either
22: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
22:21:56 <peter1138> FLHerne, trunk-ready what?
22:23:02 <FLHerne> (maybe not anymore, since he gave up and forked)
22:30:40 <peter1138> Here's how all our developers became developers: They hung around on IRC discussing stuff.
22:31:12 <peter1138> They also started by fixing things.
22:34:03 <peter1138> Waaaah they didn't accept my feature patch waaaah tends to just get ignored, especially after the likes of richk
22:35:05 <andythenorth> who did ‘close airports’ in the end?
22:35:09 <andythenorth> that’s a handy feature
22:36:36 <peter1138> I've never used it :p
22:37:05 <peter1138> Damn it, I can't play 6th notes with one hand and 8th notes on the other :(
22:41:38 <Eddi|zuHause> that's a skill you need to practice a lot :p
22:42:37 <Eddi|zuHause> luckily, i don't need that skill :p
22:47:12 *** andythenorth has left #openttd
22:58:03 <DorpsGek> Commit by peter1138 :: r27805 trunk/src/ship_cmd.cpp (2017-03-19 22:57:54 +0100 )
22:58:04 <DorpsGek> -Codechange: Remove function ShipGetNewDirectionFromTiles
22:58:05 <DorpsGek> The only user of ShipGetNewDirectionFromTiles can be better
22:58:06 <DorpsGek> served by DiagdirBetweenTiles, so remove the former. (cirdan)
22:59:33 <DorpsGek> Commit by peter1138 :: r27806 trunk/src/ship_cmd.cpp (2017-03-19 22:59:24 +0100 )
22:59:34 <DorpsGek> -Codechange: Remove function ShipGetNewDirection
22:59:35 <DorpsGek> ShipGetNewDirection has no side effects and its return value
22:59:36 <DorpsGek> is ignored by its only caller, so do away with it.
22:59:37 <DorpsGek> Also remove now unused _new_vehicle_direction_table. (cirdan)
23:02:28 <DorpsGek> Commit by peter1138 :: r27807 trunk/src/ship_cmd.cpp (2017-03-19 23:02:20 +0100 )
23:02:29 <DorpsGek> -Codechange: Remove _ship_leave_depot_offs
23:02:30 <DorpsGek> There is already TileOffsByDiagDir for that. (cirdan)
23:02:41 <peter1138> Can pick tiny patches though
23:30:55 <DorpsGek> Commit by peter1138 :: r27808 /trunk/src (rail.cpp track_func.h) (2017-03-19 23:30:47 +0100 )
23:30:56 <DorpsGek> -Codechange: Adjust the size of _track_crosses_trackdirs
23:30:57 <DorpsGek> _track_crosses_trackdirs is indexed by a Track, not a
23:30:58 <DorpsGek> Trackdir, so adjust its size accordingly. (cirdan)
23:32:00 *** mr_pants has joined #openttd
23:32:45 <Samu> ohh, fixing ship pathfinding?
23:49:32 <peter1138> Nah, just applying shit.
23:49:44 <peter1138> It's not exactly broken...
23:53:36 <Samu> ships can't correctly find the closest depot
23:53:43 <Samu> have you done something about it?
23:54:34 <Samu> it needs to pathfind for the closest depot, and not the way it is doing now
23:54:50 <Samu> it locates closest depot via DistanceManhattan :(
23:55:05 <peter1138> Ship pathfinding is expensive.
23:55:06 <Samu> i don't think i reported it
23:56:14 <peter1138> Technically manhattan distance *is* the nearest.
23:56:58 <Samu> sometimes it's unreachable :( really hurts performance
23:57:27 <Samu> I tried, but don't know how to begin
23: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
continue to next day ⏵
