Log for #openttd on 9th January 2015:
Times are UTC Toggle Colours
00:02:47  <dreck> sounds like fun :)
00:05:02  *** supermop [] has quit [Ping timeout: 480 seconds]
00:18:50  <frosch123> TheDude: i think english.txt is missing a "##plural 0", that's why eints lists 6 invalid strings
00:20:20  <frosch123> night
00:20:23  *** frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
00:38:19  *** Myhorta[1] [] has quit [Read error: Connection reset by peer]
01:08:34  *** dreck [] has left #openttd []
03:02:51  *** Flygon_ [] has joined #openttd
03:05:35  *** Flygon__ [] has joined #openttd
03:08:28  *** glx [] has quit [Quit: Bye]
03:08:46  *** Flygon [] has quit [Ping timeout: 480 seconds]
03:10:52  *** Flygon_ [] has quit [Ping timeout: 480 seconds]
03:26:15  *** Flygon_ [] has joined #openttd
03:28:56  *** Flygon__ [] has quit [Ping timeout: 480 seconds]
03:37:25  *** Flygon [] has joined #openttd
03:43:26  *** Flygon_ [] has quit [Ping timeout: 480 seconds]
03:48:19  *** supermop [] has joined #openttd
03:54:08  *** Biolunar_ [] has joined #openttd
04:01:07  *** Biolunar [] has quit [Ping timeout: 480 seconds]
04:16:24  *** DDR [] has joined #openttd
04:24:44  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Read error: Connection reset by peer]
04:28:13  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has joined #openttd
04:32:08  *** Pereba [~UserNick@] has quit [Quit: This is AdiIRC!]
04:40:33  *** itsatacoshop247_ [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has joined #openttd
04:44:37  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has quit [Ping timeout: 480 seconds]
04:49:26  *** quorzom [] has quit [Read error: Connection reset by peer]
04:59:57  *** itsatacoshop247_ [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has quit [Ping timeout: 480 seconds]
05:04:51  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has joined #openttd
05:56:02  *** Eddi|zuHause [] has quit []
05:56:16  *** Eddi|zuHause [] has joined #openttd
06:45:07  *** MTsPony [] has quit []
06:59:10  *** DDR [] has quit [Read error: Connection reset by peer]
06:59:32  *** DDR [] has joined #openttd
07:15:19  *** Supercheese [] has quit [Read error: Connection reset by peer]
07:15:51  *** Supercheese [] has joined #openttd
07:15:52  *** luaduck_zzz is now known as luaduck
07:23:02  *** DDR [] has quit [Ping timeout: 480 seconds]
07:45:11  *** liq3 [] has quit []
07:46:56  <dihedral> greetings
08:04:42  <Supercheese> Salve
08:32:28  *** pxr [] has quit [Read error: Connection reset by peer]
08:34:45  *** Yotson [~Yotson@2001:980:6ac8:1:2c9d:199a:48c9:8080] has joined #openttd
08:52:00  <peter1138> sup
08:54:47  <Flygon> Anyone got any ideas what's happened? O_o
08:56:41  <michi_cc> Flygon: Look closely where the reserved path of the train in the lower platform ends. And then rid yourself of the wrong conception that stations supposedly have built-in signals.
08:56:58  <Flygon> Oh
08:56:59  <Flygon> Crap
08:57:05  <Flygon> Holy crap
08:57:10  <Flygon> Thanks O_O
08:57:31  <Flygon> This explains a LOT
08:57:33  <Flygon> Thanks, man
08:59:21  *** HerzogDeXtEr [] has joined #openttd
09:02:20  <planetmaker> moin
09:03:09  <V453000> moooin, RAWRin, PURRin, NUTTin
09:03:18  <V453000> YET
09:08:24  *** supermop [] has quit [Ping timeout: 480 seconds]
09:15:27  *** HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
09:15:55  *** HerzogDeXtEr [] has joined #openttd
09:54:12  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has quit [Ping timeout: 480 seconds]
09:57:21  *** Supercheese [] has quit [Read error: Connection reset by peer]
09:57:55  *** Supercheese [] has joined #openttd
10:08:44  *** Supercheese [] has quit [Read error: Connection reset by peer]
10:09:18  *** Supercheese [] has joined #openttd
10:33:42  *** jjavaholic [] has quit [Remote host closed the connection]
10:49:23  * Eddi|zuHause opens a mystery folder called "~/zeug/backup" ["zeug"="stuff"]
10:58:15  *** frosch123 [] has joined #openttd
11:30:25  <peter1138> And that was the last we ever heard from Eddi|zuHause...
11:34:36  *** glevans2 [] has quit [Ping timeout: 480 seconds]
11:35:12  *** supermop [] has joined #openttd
11:36:27  *** glevans2 [] has joined #openttd
11:46:40  *** sla_ro|master [slamaster@] has joined #openttd
12:32:33  *** Supercheese is now known as Guest1242
12:32:38  *** Supercheese [] has joined #openttd
12:38:03  *** Guest1242 [] has quit [Ping timeout: 480 seconds]
13:46:16  *** supermop [] has quit [Ping timeout: 480 seconds]
14:10:04  <Elyon> frosch123, I have a few questions regarding the updated issue
14:18:21  <Elyon> first building, `yextent: 4;  // automatically extended to [4, 16], since 16 is the default for extent` <- does this not also mean that xextent will automatically become [16, 4] as the x/yoffset is swapped?
14:19:04  <Elyon> childsprite, `yoffset: -16;` <- I thought we established that we should avoid signed offsets for now?
14:19:45  <Elyon> furthermore, why shouldn't `sprite` be allowed as an array?
14:20:57  <Elyon> and why must sprite be a compile-time constant? Shouldn't global-sprite-number be possible to assign as a runtime expression?
14:22:28  *** smoke_fumus [~smoke_fum@] has quit [Quit: KVIrc 4.2.0 Equilibrium]
14:23:53  <frosch123> wrt. xextent: [16,4]: yes
14:24:01  <frosch123> wrt. childsprite offset: yes
14:24:48  <Elyon> `sprite: [platforms_set, var44 & 0x07 == 0x07 ? 3456 : 4321]` seems weird, yet supposedly both valid and should be possible to implement?
14:25:00  <frosch123> wrt. sprite: that's what index is for, for global sprite numbers it does not really matter though whether index or sprite is used
14:25:27  <Elyon> you might want a custom sprite for X-oriented but a global sprite for Y-oriented?
14:25:40  <frosch123> i thought "sprite" should not be an array, since that requires checking the orientation for the spriteset/spritegroup reference
14:26:08  <Belugas> hello
14:26:37  <frosch123> anyway, allowing "sprite" to become an array is in theory possible, but i don't consider it nice, and i don't consider it necessary :)
14:27:01  <frosch123> i really don't like testing the orientation in varact2 :p
14:27:21  <Elyon> why does it require that? Wouldn't we just resolve with var10 := spriteset_number on the X-orientation and without var10 set on the Y-orientation?
14:27:26  <frosch123> though argueably you could assign different var10 to it
14:27:51  <frosch123> also fine for me
14:29:05  <Elyon> anyway, sprite-as-array decision notwithstanding, I think the spec is fairly implementable at this point then. However!
14:29:17  *** Suicyder [~Suicyder@] has joined #openttd
14:29:39  <Elyon> `yoffset automatically extended to [12, 0]` => also `xoffset := [0, 12]` yes?
14:30:23  <frosch123> if we do the automatic swapping, then i guess we need to do it in all cases
14:30:56  <Elyon> finally, "The Y orientation is added automatically" <- this is for simplifying the implementation so that `forall spritelayouts with feature == 4, all props except sprite and palette are guaranteed arrays`?
14:31:10  <frosch123> if it's to confusing, we could also drop the automatic swapping though
14:31:35  <Elyon> I think the swapping is a use-case that will almost always be relevant
14:32:26  <frosch123> yes, but it is also confusing since you need to specify the values for the X orientation (arbitrarily choosen over Y)
14:32:53  <Elyon> in that most stations have platforms, and most platforms are (or ought to be) buildingsprites, and most platforms-as-building-sprites will need X-orientation (x|y)(offset|extent) values that need to be swapped for Y-orientation
14:33:20  <frosch123> wrt. the automatic addition of Y direction: the spritelayout must define both. so, if Y is missing, what else can you do but add it automatically?
14:33:21  <Elyon> X-orientation is the first (left) orientation in the purchase menu
14:34:17  <Elyon> frosch123: well, what I've done currently is `if hasattr('values', value): value: value.values[1]`
14:34:36  <Elyon> so that for arrays, it selects index 1, and for anything not a value it just keeps that value
14:34:53  <Elyon> two different means to the same end
14:35:32  <frosch123> but isn't that the same as: if you specify one value, it is used for both X and Y ?
14:35:44  <frosch123> (though possibly swapped)
14:36:08  <Elyon> I don't know which approach is neater; expanding to array in property validators when feature == 4, OR checking for array and extracting value[1] iff property is array
14:36:29  <Elyon> they are the same end result, yes - but which is the most sensible implementation?
14:36:36  <frosch123> oh, also about swapping: it gets more weird, if the user does "xoffset: [12, 4]; yoffset: 5"
14:36:47  <frosch123> here the 4 and 5 somewhat contradict
14:36:56  <Elyon> hmm ...
14:37:30  <frosch123> Elyon: sorry, i cannot give you implementation recommendations :) you probably know that part of the code better than me
14:38:28  <Elyon> not necessarily. Anyway, expanding every property to and array complicates the validators but simplifies the layout-duplicator
14:39:06  <Elyon> and my thought was that the value is swapped, yet the swap only actually happens for a specific orientation if that value isn't explicitly set
14:39:29  <frosch123> so, well, i am not sure about the swapping :) it looks useful, but can also result in quite weird effects
14:39:42  <Elyon> so, `xoffset: [12,4]; yoffset: 5` => `xoffset: [12,4]; yoffset: [5,12]`
14:40:18  <Elyon> ie. the swap only sets the value if the value is not already explicitly set
14:40:26  <Elyon> that seems the most sensible to me
14:40:49  <frosch123> yup
14:40:53  <Elyon> `if user sets value: use value else: use swapped`
14:41:25  <Elyon> that way we keep the best of both worlds without having surprising results for any of the swapping
14:41:42  <Elyon> or at least minimally surprising
14:41:58  <Elyon> I'd like to keep the swapping though since it'll be used in what, 95% of cases?
14:42:28  <Elyon> or rather, 95% of non-default (x|y)(offset|extent) cases, you will want the swap to happen
14:43:12  <Elyon> if the values are default then it swaps `16` and `16` which is pretty expected result anyway :P
14:43:24  <Elyon> (for xextent that is)
14:44:03  *** Defaultti [] has quit [Quit: Quitting.]
14:44:17  <Elyon> I think that honouring authored explicit values makes the swap "not weird"
14:44:36  <frosch123> the default values are 16, 16 for the extent, which would match for non-track tile
14:44:55  <Elyon> indeed
14:44:59  <frosch123> for track tiles you have to set xoffset and xextent already, setting the others only adds two more lines
14:45:16  <frosch123> so, it does not safe that much, does it? anyway, swapping is fine
14:45:24  <Elyon> it does save quite a lot
14:45:44  <frosch123> fine, cats will show anyway, what's used
14:45:58  *** Defaultti [] has joined #openttd
14:46:43  <Elyon> for two full platforms (the case in ~90% of station-track-tiles I think), you can specify `yextent: 4` for the top platform and `yextent: 4; yoffset: 12` for the bottom platform
14:47:58  <Elyon> as opposed to `yextent: [4, 16]; xextent: [16, 4]` for top and `yextent: [4, 16]; xextent: [16, 4]; yoffset: [12, 0]; xoffset: [0, 12];`
14:48:19  <Elyon> the latter (the 90% use case) seemingly introducing a tonne of redundancy
14:49:27  <Elyon> like, every single `4`, `16` and `12` are referring to /the same logical value/ in 90% of use cases, so duplicating it for every (x|y)(offset|extent) seems both excessive and redundant
14:49:38  <Elyon> redundancy is an error vector
14:50:31  <Elyon> there are four `4`s, four `16`s, two `12`s and two `0`s
14:51:04  <Elyon> whereas with inferrence and autoswap, that becomes two `4`s and one `12`
14:51:12  <frosch123> true, with the swapping you get rid of all 0 and 16
14:51:37  <Elyon> as well as the /need/ to specify xextent every time you specify yextent
14:51:55  <Elyon> I figure the way for the author to consider spritelayout for station is that they define:
14:52:05  <Elyon> 1) layout as X-orientation
14:52:25  <Elyon> 2) optionally for each param explicitly provide a value for Y-orientation
14:52:44  <Elyon> 3) and 2) is inferred sensibly if omitted
14:53:18  <Elyon> the swap approach adheres to the 'DRY' and 'convention over config' philosophies
14:53:50  <Elyon> both of which reduce number of errors /and/ codelines/complexity
14:54:53  <Elyon> like, in the explicit case if you want to change the extents from [16, 4] to [15, 3] ... you have to change the 16 -> 15 four times, and same applies for the 4 -> 3
14:55:12  <Elyon> introducing a high likelihood of mistakes compared to specifying each value just once
14:56:00  <Elyon> makes code less errorful, more maintainable - I can't really think of a reason /not/ to do inferrence/swap :p
14:56:09  <Elyon> s/code/nml code
15:02:51  <Elyon> also, for maximum customisability: it should be possible to support 7 spritesets/groups per layout /per orientation/ without checking orientation in a varact2
15:03:04  <Elyon> wait, no, it wouldn't
15:03:06  <Elyon> nevermind
15:03:32  <Elyon> 7 sprite(sets|groups) in total for one layout. Should be enough anyway
15:04:44  <frosch123> yes, it should be very unlikely that X and Y use different sets/groups
15:05:07  <frosch123> i would expect at most: 1 set for ground, 1 for buildings, 1 for palettes
15:05:17  <Elyon> yeah possibly
15:05:24  <frosch123> hmm, maybe 1 for cargos
15:05:33  <frosch123> still 4 instead of 7 :)
15:05:37  <Elyon> but even then, I still think we should support sprite-as-array
15:05:50  <frosch123> sure, it's more
15:05:51  <Elyon> while still keeping the hard cap of 7 spritesets per layout
15:06:08  <Elyon> for example, imagine ...
15:06:23  <Elyon> spriteset x_platforms { ... }
15:06:29  <Elyon> spriteset y_platforms { ... }
15:06:49  <Elyon> then building { sprite: [x_platforms, y_platforms]; }
15:07:27  <Elyon> so long as the author stays <= sets/groups in total I don't see why we shouldn't support that
15:07:46  <Elyon> doesn't require orientationchecking, just requires setting var10 differently for the two layout orientations
15:07:55  <Elyon> /in/ the layouts
15:10:18  <Elyon> I can imagine ground: 1set, buildings: 2set, platforms: 2sets, palettes: 2sets, cargos: 1set - this is 8 sets in total
15:10:42  <Elyon> so the hardcap of 7 might very well be reached if your platforms and buildings are in separate spritesets per orientation
15:11:19  <frosch123> i guess we can write the documentatio accodingly
15:11:25  <Elyon> and even with platforms in same set, and buildings in a different set, we still reach 5 used sets
15:11:28  <frosch123> and recommend alternating orientations within spritesets :)
15:11:35  <Elyon> indeed
15:12:26  <Elyon> so 5 used sets for a fairly logical separation of spriteset graphics files - and this isn't even considering any grf-specific usecases which might very well end up using another set or two
15:13:02  <Elyon> point being we should encourage or at least allow logical separation of spritesets
15:14:19  <Elyon> for cats for example, the graphicswill probably be separated into [groundset, buildingset, platformset, paletteset, cargoset, signalset] at the very least
15:14:46  <Elyon> maybe an additional `fluffset` as well, in which case we would exactly hit the 7 set limit
15:16:39  <Elyon> anyway, I shall adhere to the tentative undocumented suggestions and decisions we have discussed now :p
15:19:34  <planetmaker> but one spriteset can hold 255 sprites, can't it?
15:19:48  <Elyon> a spriteset can hold at lot more I think
15:19:55  <planetmaker> thus I don't see 7 spritesets as a real limit in that case (though I'm sure someone would find it ;) )
15:20:21  <frosch123> yes, 64k per spriteset
15:20:34  <Elyon> it's not a limit, but encouraging/supporting a logical separation of sprites into different sets seems like a good approach to me
15:21:31  <planetmaker> hm, no idea why that would be needed and why I would separate them into different spritesets. Why is it good?
15:21:40  <Elyon> if you absolutely desperately /need/ more than 7 logical separate sets you will have to combine some of them into <= 7 primary separate sets
15:22:15  <Elyon> pm: logical separation means better code readability
15:22:17  <planetmaker> My approach to spritesets is to use one big one and reference the sprites by offset (or name)
15:22:28  <planetmaker> true, that might be
15:22:38  <planetmaker> but you can name sprites in spritesets :)
15:22:49  <planetmaker> iirc
15:23:00  <Elyon> `sprite: cargo; index: 14` is more readable than `sprite: all_mai_spraits; index: 14777`
15:23:08  <frosch123> planetmaker: not all sprites use little/lots variations
15:23:14  <Elyon> pm, wait what?
15:23:26  <frosch123> the sprites that use little/lots need to be a in a different set, than those who do not use little/lots
15:23:50  <Elyon> individual sprite LABELLES?!
15:24:09  <Elyon> this. is. amazing.
15:24:13  <frosch123> no, i think there were names for spritesets in spritegroups
15:24:40  <Elyon> frosch123: "Each sprite may be prefixed with a label"
15:24:41  <frosch123> <- hmm, or maybe there is
15:24:57  <Elyon> means we can have nmlcode like this:
15:25:20  <Elyon> `sprite: concrete_platform_sprite; index: [2,3];`
15:25:34  <Elyon> instead of `sprite: platforms; index: [14, 15];`
15:25:47  <Elyon> self-documenting code!
15:26:17  <frosch123> that won't work for spritegroups though
15:26:27  <frosch123> since you need to reference the spritegroup, but the label is in the spriteset
15:26:39  <planetmaker> yes
15:26:59  <frosch123> when using spritegroups, it's the job of the user anyway, to make sure the spritesets are in sync
15:27:03  <Elyon> chances are you won't need/don't know specific sprites at compile-time for little/lots anyway
15:27:07  <planetmaker> sprite: groundtile_spriteset(this_groundtile_label)
15:27:16  <planetmaker> ;
15:27:22  <Elyon> pm, is that the syntax?
15:27:38  <planetmaker> I think that's how you would reference the sprite with that label, yes
15:27:50  <Elyon> ah okay
15:28:00  <Elyon> so `sprite: platforms(concrete)`
15:28:18  <Elyon> index: [0, 1] as well probably
15:28:20  <planetmaker> the usual approach to reference the n-th sprite in a spriteset is: sprite: spritesetname(index);
15:28:43  <planetmaker> where index is the sprite (starting 0-counting) you want to reference in the spriteset
15:29:03  <Elyon> frosch123: what do you think of allowing spriteset/spritegroup indexing/labelusing in the end anyway?
15:29:24  <planetmaker> index could also be an expression like tileslope + 18 * anim_stage
15:29:39  <frosch123> it would be nice, but i have no idea how it could possibly work with spritegroups :)
15:29:46  <Elyon> would allow for sprite labels, AND simplify `index: [0, 1]` in most cases, AND make code inherently readable without comments
15:29:51  <frosch123> planetmaker: index works differently for stations
15:30:27  <Elyon> so an elaborate example of what I think we /should/ support:
15:30:36  <frosch123> "sprite: plaforms(concrete + [0,1])" resp. "sprite: plaforms(concrete) + [0,1]" is too weird/complicated, hence we split "sprite" and "index"
15:30:47  <frosch123> but now we are about adding two indices :p
15:31:10  <frosch123> (though argueably for global sprites we already have two indices)
15:31:21  <planetmaker> frosch123, yes, I fear the differences :)
15:31:34  <planetmaker> it's a big PITA that stations are so different from the rest
15:31:38  <Elyon> well in fairness, we would encourage the sprite index as an absolute offset, and the index property as the relative offset
15:31:48  <planetmaker> maybe grf v9 should introduce an identical way for them :P
15:32:12  <frosch123> planetmaker: nope, we abstracted it already, so it is the same
15:32:14  <Elyon> `sprite: platforms(concrete + variant); index: [0, 1];`
15:32:22  <frosch123> just that stations have orientations, while houses have not
15:32:39  <frosch123> and that stations are expected to look the same in both orientations, while objects are entirely different
15:32:40  <Elyon> ^ what do you think of that supported indexing feature?
15:32:45  <planetmaker> can you remind me: this index... what does it index?
15:33:05  <frosch123> it's the parameter to the spriteset
15:33:12  <frosch123> just that there are two: for both orientations
15:33:16  <Elyon> spriteset/spritegroup offsets to find the absolute position within the set/group, and index property to offset slightly within the logical subseparation
15:33:59  <planetmaker> nah, then: sprite: [spritesetname(xsprite), spritesetname(ysprite)]
15:34:07  <frosch123> also, there is the little/lots thingie, which neither houses nor objects have
15:34:09  <planetmaker> that's imho more accessible
15:34:11  <Elyon> planetmaker: huh
15:34:22  <planetmaker> if you need an x and a y sprite for each
15:34:26  <planetmaker> less boilerplate
15:34:35  <planetmaker> and no absolute and relative maths combined
15:34:36  <Elyon> and we'd avoid introducing a new property
15:34:45  <planetmaker> why new property?
15:34:55  <Elyon> `index: ` is a new property
15:35:04  <frosch123> planetmaker: isn't that syntax completely redundant?
15:35:08  <Elyon> a pseudoproperty, at that
15:35:26  <planetmaker> frosch123, how so? One for the x-orientation sprite, one for the y-orientation? (I might miss some crucial step)
15:35:42  <frosch123> you put "spritesetname" twice
15:35:50  <frosch123> also, "spritesetname" is wrong, it is "spritegroupname"
15:36:04  <Elyon> pm's suggestion seems solid to me. Also allows referincing different spritesets/groups based on orientation
15:36:07  <frosch123> and parameters to spritegroups are very confusing, "index" is imho way supperious
15:36:14  <Elyon> frosch123, really?
15:36:24  <planetmaker> frosch123, it's just a $spritesetname1 - whatever name it has
15:36:26  <frosch123> let's make a proper example with spritegroups
15:36:30  <Elyon> pm made a valid point in that having two indices, one absolute and one relative, is a bit overkill
15:36:31  <planetmaker> ok
15:37:06  <Elyon> I think two indices is /more/ rendundancy than potentially referencing the same spriteset/group twice with different indices
15:37:14  <Elyon> s/indices/index properties/
15:37:22  <frosch123>
15:37:34  <frosch123> "index" selects the sprite in station2..4
15:37:52  <frosch123> puting it in () behind "spritegroup2" would suggest it would select little/lots
15:37:55  <frosch123> which it does not
15:38:30  <Elyon> hmm ...
15:39:06  <frosch123> putting any parameter after the group makes it very weird to me; besides that i think "index" is way easier to implement
15:39:22  <frosch123> since it makes it easier to detect when var10 can be shared
15:39:44  <planetmaker>
15:40:07  <frosch123> planetmaker: where is little/lots in that example?
15:40:10  <planetmaker> ah :)
15:40:15  <planetmaker> nowhere yet
15:40:57  <Elyon> `sprite: platforms(concrete + variation); index: [0, 1];` => platform set selection, concrete platform setsection selection, concrete platform variant setsection selection, orientation offsetting
15:41:24  <Elyon> seems ideal from a code readability/low redundancy point of view
15:41:27  <planetmaker> this little/lots... that's mandatory, yes?
15:41:47  <Elyon> it's mandatory to support, but generated by default if you reference spritesets instead of spritegroups
15:41:53  <frosch123> planetmaker: that's how stations work :p
15:42:05  <planetmaker> yeah, sorry, I need to ask. I don't know how they work :)
15:42:23  <planetmaker> why does the 'little' only reference one spriteset in your layout?
15:42:36  <frosch123> industries/houses have construction stage, objects have view; but stations have two properties: orientations and cargo amount
15:43:01  <frosch123> [16:42] <planetmaker> why does the 'little' only reference one spriteset in your layout? <- so i had less to type?
15:43:08  <Elyon> :D
15:44:06  <planetmaker> hm... then I don't get how the spritegroup works there... shouldn't the amount of sprites be identical?
15:44:08  <frosch123> (actually, cut the "view" for objects, it's not comparable)
15:44:25  <frosch123> planetmaker: inside the spriteset
15:44:37  <planetmaker> ok, but same amount of sprites  for little and lots?
15:44:48  <frosch123> little/lots is just like vehicles loading/moving
15:44:49  <Elyon> anyway, I think the idea of supporting `spriteset(label/index)` is valid, yet doesn't remove the need for the `index: []` property
15:44:59  <frosch123> you do not need the same amount for moving and loading
15:45:09  <frosch123> for closed vans you only have one moving
15:45:21  <Elyon> both approaches have their uses - sometimes concurrently
15:45:33  <frosch123> Elyon: but how to resolve the label?
15:45:48  <frosch123> should the spritegroup inherid the labels from all/the first spriteset?
15:45:50  <Elyon> frosch123, labels are only supported when spritesets are referenced, not when spritegroups are
15:45:57  <frosch123> ok :)
15:46:04  <Elyon> I think that makes the most sense?
15:46:29  <Elyon> with a `TODO:` comment somewhere about supporting spritegroup label inheritance in the future
15:47:28  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
15:47:38  <planetmaker> hm...
15:52:29  *** TheMask96 [] has joined #openttd
15:52:45  <planetmaker> <-- revised suggestion
15:53:02  <planetmaker> thus the index is passed-through right to the spritesets
15:53:19  <planetmaker> if you specify any
15:53:22  *** pxr [] has joined #openttd
15:53:29  <frosch123> that uses different spritegroupos for x and y, which is exactly what should be avoided :)
15:53:36  <planetmaker> you can use the same
15:53:53  <planetmaker> no-one forces you to use different ones
15:53:55  <frosch123> it's also very long
15:53:59  <planetmaker> just specify the same and different index
15:54:16  <frosch123> stations are designed so both directions work a and look the same
15:54:17  <planetmaker> and I don't think it's longer than specifying a separate index property
15:54:25  <planetmaker> it's consistent with how vehicles work with the groups
15:54:32  <planetmaker> yes
15:54:50  <frosch123> in your example you distinguish the orientation on the top-level, which nml would have to detect to be identical, or create a hell of a grf :p
15:55:33  <planetmaker> I don't see the problem?
15:55:56  <frosch123> well, my opinion was to only allow referencing one spritegroup/set independent of orientation
15:55:56  <planetmaker> you have to distinguish something
15:56:16  <frosch123> elyon argumented that it is not much harder to *allow* specifying them differently
15:56:32  <frosch123> pm makes it the default case, which is imho wrong
15:56:51  <frosch123> following that approach you are back to layoutsgroups from 2 days ago
15:56:52  <planetmaker> this approach allows you to choose spritesets however you like. And you can pass-through any index like you want. Without any magic
15:56:58  <frosch123> they would make it exactly the same as objects
15:57:10  <frosch123> but the would also not at all enforce x and y to be identical
15:57:12  <frosch123> which is just wrong :p
15:57:31  <planetmaker> you cannot enforce that anyway at all?
15:57:47  <frosch123> or just no layoutgruops at all, just use the same layout, and let the user check the orientation in a switch
15:58:00  <frosch123> but again, you are completely remoing the built-in mechanic of handling orientations the same
15:58:13  <frosch123> which is just brushing the donkey from the wrong side :p
15:59:42  <frosch123> planetmaker: you are treating stations like objects
15:59:58  <frosch123> objects have a "view" variable, and then allow the newgrf do select a spriteset depending on the view
16:00:07  <frosch123> "view" is a complete grf thing
16:00:34  <frosch123> stations on the other hand have built-in orientations, and everything in ottd is about making them behave the same
16:00:38  *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
16:00:42  *** mode/#openttd [+o Alberth] by ChanServ
16:00:49  <planetmaker> yes...?
16:00:51  <frosch123> by treating them like "views" you work completely against the logic in ottd
16:01:00  *** Myhorta [] has joined #openttd
16:01:17  <frosch123> the "orientation" thus must be the very last switch in nml
16:01:32  <frosch123> not the 3rd last after set, group and custom offsets
16:02:46  <planetmaker> can you elaborate on the 'must'? What is being lost?
16:02:51  <frosch123> in fact i think "nml" should completely hide the "orientation" aspect
16:03:04  <frosch123> else you end up with tiles that are track tiles in X, and non-track in Y
16:03:36  <planetmaker> ok... so the spritelayout distinguishes xdir and ydir. And the little/lots is found in the sprite definition?
16:03:36  <frosch123> planetmaker: my_station_x and my_station_y is compeltely redundant
16:03:45  <planetmaker> vice versa than I specified?
16:03:45  <frosch123> they must be the same to make any sense
16:03:49  <Elyon> ^
16:04:10  <frosch123> but since they are not the same by syntax, nml has to create a hyper-complex distinguishing between the cases
16:04:53  <frosch123> splitting "sprite" and "index" separates the sprite selection from the orientation
16:05:01  <frosch123> sprite comes firs, then little/lots, then index
16:06:36  <frosch123> or to put it differently: the nml syntax should suggest to put orientations alternating into spritesets, since that's the most natural form in the grf
16:06:43  <planetmaker> <-- so... not like that either?
16:06:47  <frosch123> which benefits everyone :p
16:07:26  <planetmaker> hm. I don't see why I couldn't have all X first and then all Y :)
16:07:28  <frosch123> planetmaker: i have no idea how to compile that
16:07:37  <planetmaker> in a spriteset
16:08:02  <frosch123> also "little/lots" are not two entries
16:08:16  <frosch123> anyway, i don't see the discussion going anywhere
16:08:41  <Elyon> ;3
16:10:11  <planetmaker> I really don't see how specifying the index for the y and x orientation separately is any different
16:10:30  <frosch123> because that is how grfs work
16:11:07  <planetmaker> you want sprite: spritegroup; index: [x, y]; I suggest: sprite: [spritegroup(index), spritegroup(indexy)]
16:11:08  <frosch123> i really cannot explain why "index" is natural, and a random other ordering is not natural
16:11:28  <frosch123> planetmaker: your suggestions are like swapping loading stages and orientations for vehicles
16:11:43  <frosch123> you cannot make nml completely different from grfs
16:11:59  <frosch123> vehicles to not have more power when driving in one direction
16:12:14  <planetmaker> sailing vessels :P
16:12:21  <frosch123> you cannot define vehicles with 6 directions
16:14:05  <planetmaker> ok, then I see no way around using absolute offsets into the spriteset and relatives for the index
16:14:19  <planetmaker> which is... confusing
16:15:08  <frosch123> possibl,y but then i would drop the absolute offset, not the relative ones :p
16:15:33  <planetmaker> that's ugly. No shared ground tiles or building parts
16:15:33  <Alberth> group x and y direction together?
16:15:43  <planetmaker> that's what I try to suggest, Alberth :)
16:16:19  <frosch123> [17:15] <planetmaker> that's ugly. No shared ground tiles or building parts <- i don't follow why that would be the case
16:16:37  <Alberth> drop "xdir:" and "ydir:", and use  [ x-stuff,  y-stuff]    or so
16:16:40  <frosch123> Alberth: funnily i suggest the same
16:16:41  *** quorzom [] has joined #openttd
16:17:05  <Alberth> ok, didn't read backlog :)
16:17:28  <planetmaker> hm. Maybe no parameter for the spritegroup, but like: (I know that not all slopes make sense)
16:18:03  <planetmaker> index then being an absolute entry into the spriteset
16:18:14  <frosch123> planetmaker: that looks exactly what i mean
16:18:24  <Alberth> line 6 is 1 direction?
16:18:32  <frosch123> both
16:18:38  <Alberth> oh, nice
16:23:06  <planetmaker> hm...
16:23:55  <planetmaker> <-- less boilerplate that way?
16:24:32  <frosch123> how to do global sprites then?
16:25:17  <planetmaker> How do you mean? I don't understand your question...
16:25:31  <planetmaker> you mean it conflicts with the current implementation of sprite:... ?
16:25:36  <frosch123> GROUNDSPRITE_RAIL_X
16:25:55  <Elyon> elaborate example of some of the features we need in CATS, and how I would personally like to be able to define those stations:
16:25:58  <Elyon>
16:25:59  <planetmaker> how is it handled by your approach currently?
16:26:25  *** TheDude [~Thed@2a02:2b88:2:1::1d73:1] has left #openttd [I'm a happy Miranda IM user! Get it here:]
16:27:07  <frosch123> planetmaker: sprite: GROUNDPSRITE_RAIL_Y; index: [0, -1]
16:27:31  <planetmaker> o_O
16:27:42  <planetmaker> not [-1, 0] ?
16:27:59  <Elyon> RAIL_Y index < RAIL_X index
16:28:09  <frosch123> no, funnily Y is before X ni default sprites :p
16:28:12  <frosch123> we also fell over that :)
16:28:13  <Elyon> yaaay
16:28:40  <frosch123> anyway, the idea is to hide the default track ground including railtype selection in a marco
16:28:41  <planetmaker> then it would need to be GROUDSPRITE_RAIL_X; index: [0,-1]
16:28:58  <frosch123> it's way to complicated to explain it to grf authors, and there is zero variation
16:29:20  <frosch123> <- see second line
16:29:22  <Elyon> frosch123, mind if I post as a comment/syntax-suggestion on the open issue?
16:30:12  <frosch123> Elyon: it's fine, but i would suggest to paste the content, not only the link, since sp*ke changes it all the time (pun)
16:30:19  <frosch123> also add some bullet points, what changed
16:30:31  <Elyon> frosch123: yes, that was my intention, at least with the full content paste
16:30:32  <frosch123> like "sprite" allowing an array, but not recommending it
16:30:36  <planetmaker> frosch123, can we have a keyword 'ref_base_sprites' or so and directly give the sprite numbers in the index then?
16:30:45  <planetmaker> that's less magic than what you quoted
16:31:10  <frosch123> planetmaker: huh? it's a single word "ground_track"
16:31:13  <Elyon> huh, what's happening? isn't spriteset/group reference == customsprite, and constantnumeric == defaultsprite?
16:31:18  <frosch123> there are no parameters or whatsoever
16:31:53  <planetmaker> sprite: 0; index: [GROUNDSPRITE_RAIL_X, GROUNDSPRITE_RAIL_Y];
16:31:58  <planetmaker> easier for me to comprehend
16:32:04  <planetmaker> same thing, though
16:32:04  <frosch123> but it's wrong
16:32:10  <planetmaker> ?
16:32:10  <frosch123> no, it's not the same
16:32:14  <Elyon> frosch123, there is no `sprite: array`s in the example there
16:32:18  <frosch123> yuo need to add a offset for monorail and maglev
16:32:27  <frosch123> and you ened to add offsets for snow
16:32:41  <Elyon> groundsprite_rail takes care of at least railtype
16:32:50  <frosch123> or in other words: you need to do exactly what ottd expects to insert railtype graphics
16:32:51  <Elyon> dunno about snow, I was of the expression that it did that as well
16:32:59  <Elyon> it's a magic defaultsprite tbh
16:33:04  <frosch123> so, there is zero variation for the user, and the user should not have to type it at all
16:33:16  <planetmaker> eh...?
16:33:51  <frosch123> planetmaker: stations come with a default offset into the spriteset using the fallback-railtype
16:34:02  <planetmaker> yes, they do
16:34:11  <frosch123> you never need that, thus the nml syntax disables it, and even disallows using it
16:34:18  <frosch123> except: it is needed for the track ground sprite
16:34:51  <Elyon> frosch123, are you sure? sprite 1012/1011 automagically handles railtype
16:34:58  <Elyon> and groundtype iirc as well
16:35:01  <frosch123> planetmaker: essentially, the macro should do exactly, what SplitGroundSpriteForOverlay() expects
16:35:09  <frosch123> there is no point in letting the grf author do that
16:35:43  <planetmaker> frosch123, but then your index is relative... not absolute
16:36:32  <planetmaker> sprite: GROUNDPSRITE_RAIL_Y; index: [0, -1]    <===>  sprite: 0; index: [GROUNDSPRITE_RAIL_X, GROUNDSPRITE_RAIL_Y] is different?
16:36:54  <frosch123> you miss the "+ railtype-magic"
16:37:06  <frosch123> there is no equivalant to "+ railtype-magic" in the current nml syntax
16:37:22  <frosch123> since it is only needed in that one place, and not wanted by anyone in any other case :p
16:37:47  <planetmaker> yes... nml does not need that exposed... but could add it. automatically
16:37:50  <planetmaker> if sprite==0
16:38:00  <planetmaker> hm
16:38:01  <Elyon> or sprite is undefined?
16:38:13  <Elyon> ground {}
16:38:18  <frosch123> as said: stations come with a default railtype offset, nml always disables that, because it is stupid. except: the track ground sprite must use it
16:38:22  <planetmaker> why does it add that automatically with  sprite: GROUNDPSRITE_RAIL_Y; index: [0, -1] ?
16:38:25  <frosch123> planetmaker: really, what's your point?
16:39:14  <planetmaker> <planetmaker> sprite: GROUNDPSRITE_RAIL_Y; index: [0, -1]    <===>  sprite: 0; index: [GROUNDSPRITE_RAIL_X, GROUNDSPRITE_RAIL_Y] is different? <<--- that. I don't see the difference, if there's no magic anyway. Or *where* is the difference?
16:39:37  <frosch123> yes, they are the same, but they are both *wrong*
16:39:43  <planetmaker> ok
16:39:44  <frosch123> both are missing *railtype-magic*
16:40:02  <frosch123> that's why there is a speical "ground_track", since that's the *only* place that ever needs that
16:40:06  <planetmaker> I assumed you pasted a correct and working example
16:40:11  <Elyon> :p
16:40:11  <frosch123> and since it makes no sense to put anything else there
16:40:35  <planetmaker> ok. That makes sense
16:40:36  <frosch123> *sigh*
16:40:45  * planetmaker hugs frosch123
16:41:22  <Elyon> so tl;dr := "implement ground_track macro, receive tofu"
16:41:31  <Elyon> s/tofu/bacon if desired
16:41:33  <planetmaker> :)
16:41:45  <Elyon> :D
16:41:46  <planetmaker> that was mean. I instantly got hungry :(
16:42:33  <Elyon> sowwy
16:42:37  <Alberth> /me shares food
16:42:56  <Elyon> "food, otherwise unspecified"
16:43:33  <frosch123> Elyon: what are those "signal" sprites in cats?
16:43:48  <Alberth> being virtual food, it automagically transforms to the food type you desire :p
16:43:57  <frosch123> are they protest-signs? "we want a train"?
16:44:05  <Elyon> XD
16:44:09  <frosch123> rampaging yetis waiting for the train?
16:44:18  <planetmaker> yummi, Alberth :)
16:44:37  <Elyon> well no, I thought of adding a signal that is green when platform is free, yellow when it's reserved, and red when it's occupied
16:45:06  <frosch123> ah, i don't think you can distinguish reserved and occupied though
16:45:12  <Elyon> sure you can
16:45:27  <frosch123> really?
16:47:14  <Elyon> frosch123: var18 bits 3 and 4: "train (enters|leaves) station"
16:47:26  <Elyon> just have to use some clever animation state changes
16:47:47  <frosch123> oh, animation triggers have them?
16:47:50  <Elyon> yarp
16:48:01  <Elyon> and it's platform specific as well
16:48:08  <Elyon> exactly as needed
16:48:39  <Elyon> so at a glance even with roofed stations, you can see which platforms are occupied, which are about to be occupied, and which are free :3
16:49:21  <Elyon> perhaps we could even have a red+yellow signal when it's about to become green
16:49:25  <Elyon> for maximum AWE
16:49:56  <Alberth> shouldn't free be red, as in "being idle now"  ?  :)
16:50:03  <Elyon> naw
16:50:13  <Elyon> red is "OTHER TRAINS: DON'T GO HERE"
16:50:30  <Alberth> fair enough
16:50:34  <Elyon> yellow is "other trains: don't go here it's almost occupied"
16:50:42  <Elyon> green: "go here NAO"
16:50:49  <Elyon> red+yellow: "don't go here ... yet!"
16:50:52  <Alberth> :)
16:51:50  <Elyon> or some such silly suggested station supported signalling
16:53:03  <frosch123> yeah, we'll forward all bug reports
16:53:09  <frosch123> about signals mis-behaving
17:01:06  <Alberth> make it behave like race-start lights?
17:04:56  <Elyon> >:3
17:05:04  <Elyon> genius!
17:05:25  <Elyon> frosch123: <- adequate? ready for initial implementation?
17:05:51  <frosch123> i have the suspicion, that pass-through trains will just drive through red signals :p
17:06:37  <b_jonas> frosch123: uh... they shouldn't
17:08:26  <Elyon> b_jonas: I think frosch123 is talking about the signalfluff of CATS Adaptive Train Stations, not /actual/ functional signals :p
17:10:45  *** frosch [] has joined #openttd
17:10:49  <frosch> how rude
17:10:51  <frosch> Elyon: it's certainly a superset of what a first implementation would need :)
17:10:54  <Elyon> wat happn
17:11:20  <frosch> my router ocassionally out-of-mems or so :p
17:11:31  <Alberth> we have two fr0sches now
17:11:42  <Elyon> we doooo
17:11:57  <frosch> one of them will highlight me on all channels shortly :/
17:15:07  *** frosch123 [] has quit [Ping timeout: 480 seconds]
17:16:06  *** MTsPony [] has joined #openttd
17:17:34  <Elyon> frosch: :(
17:18:32  <Sheogorath> O.o another german
17:18:45  <Elyon> with mq, if I want to dequeue a patch, I just qpop it and it keeps the patchfile while removing the queued commit?
17:19:30  <frosch> qpop and qpush move the working copy, not changing the patch files
17:19:47  <Elyon> which is what I want I guess
17:20:47  <frosch> if you want to alter one patch file, you do qpop until the working copy is at that position
17:20:50  <Elyon> I have a half-implemented station-spritelayout-properties-as-arrays patch that I want to unapply, without losing the patchfile (because I will use it as a reference for reimplementing properties-as-arrays properly)
17:20:57  <frosch> then you edit, then you do qrefresh
17:21:19  <frosch> Elyon: qpop will not delete any data
17:21:51  *** Quatroking [] has joined #openttd
17:22:25  <Elyon> wondarfull, `hg qpop && hg qnew -m 'Feature: spritelayout property array values' station-spritelayout-property-array-values` is probably what I need then :D
17:22:28  <Elyon> thanks!
17:22:55  <Alberth> and qrm to delete the partial afterwards
17:23:13  <Alberth> also, you can load the patches in an editor/viewer   from .hg/patches
17:24:02  <Elyon> Alberth: ah, yes :)
17:24:03  <Alberth> (don't edit them, as you change the file directly)
17:24:28  <Alberth> unless you want to live at the edge :p
17:24:59  <Elyon> well I had some trouble figuring out how to change the commit-message without editing ".hg/patches/the-patch" directly
17:25:12  <Alberth> hg qref -e    iirc
17:25:33  <frosch> i edit unapplied patch files all the time :p
17:25:49  <Elyon> you're living on the edge then :p
17:26:00  <Alberth> /me lives at the edge too
17:26:12  <frosch> sometimes editing a patch file before qpush is easier than resolving the conflict afterwards :)
17:26:23  <Alberth> I even change the  @@ numbers :p
17:27:32  <Alberth> make sure you keep a backup though if they are really important, the patches are not version controlled
17:27:33  <frosch> cool, so i am not the only douchbag ignoring fancy merging tools :p
17:28:10  <Alberth> :D
17:32:59  *** Taede [] has quit [Ping timeout: 480 seconds]
17:37:09  *** Taede [] has joined #openttd
17:47:24  *** quorzom_ [] has joined #openttd
17:47:30  *** quorzom [] has quit [Read error: Connection reset by peer]
17:47:30  *** Quatroking [] has quit [Read error: Connection reset by peer]
17:47:44  *** Quatroking [] has joined #openttd
17:53:46  *** glx [] has joined #openttd
17:53:49  *** mode/#openttd [+v glx] by ChanServ
17:55:37  *** Progman [] has joined #openttd
18:26:11  *** oskari89 [] has joined #openttd
18:26:17  *** gelignite [] has joined #openttd
18:30:16  *** Biolunar_ [] has quit [Quit: yo.]
18:37:22  <planetmaker> Elyon, hg qrefresh -m "New message" should work, too
18:37:31  <planetmaker> when the patch is your currently checked-out patch
18:37:32  *** HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
18:37:56  *** HerzogDeXtEr [] has joined #openttd
18:43:06  *** luaduck is now known as luaduck_zzz
18:45:16  *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
18:55:20  *** Klanticus_ [] has quit [Remote host closed the connection]
18:59:12  *** oyvind [] has joined #openttd
18:59:42  *** oyvind is now known as Gather
19:01:52  <Gather> hmm i can find my server on the multiplayer display in openttd but get a timeout when trying to create a company. Any ideas? (running out of the box config .. just running openttd -D)
19:02:44  <Gather> running 1.4.4
19:03:17  <Eddi|zuHause> Gather: timeouts can be set in openttd.cfg
19:03:35  <Eddi|zuHause> (on the server)
19:08:33  <Gather> The server says "The server didn't answer the request" but i guess thats a timeout?
19:12:19  *** andythenorth [] has joined #openttd
19:13:20  <andythenorth> o/
19:21:15  *** Progman [] has quit [Remote host closed the connection]
19:21:24  <Gather> Eddi|zuHause: hmm i set max_join_time to 10000 and max_download_time to 15000 still same problem
19:22:01  <Eddi|zuHause> have you reloaded the config on the server?
19:22:16  <Gather> Eddi|zuHause: I stopped and started the server
19:22:24  <Gather> but i think i might not be editing the right config
19:22:44  <Eddi|zuHause> you have to stop the server before editing the config, otherwise your changes will be overwritten
19:23:19  <Gather> aha
19:23:20  <Gather> :)
19:23:23  <Gather> lets give it a try
19:27:02  *** liq3 [] has joined #openttd
19:27:05  <Gather> ok atleast its the right config.. changed the name of the server and it worked
19:28:21  <Gather> lets check the fw logs :)
19:33:21  *** Wolf01 [] has joined #openttd
19:33:43  <Wolf01> hello o/
19:34:46  <andythenorth> lo Wolf01
19:38:50  <Wolf01> andythenorth, do you know somebody who succeeded to build a lego ferris wheel using the 157,5° technic angle elements?
19:39:07  <andythenorth> no but where did you look so far?
19:39:25  <andythenorth> brickshelf? mocpages?  flickr?
19:39:33  <Gather> Eddi|zuHause: i wonder if the "The server didn't answer the request" is a timout or infact something else
19:40:04  <Eddi|zuHause> well, it could be a misconfigured firewall/router
19:40:10  <Wolf01> just wikipedia and wolfram alpha for trigonometric formulae to calculate the right length of the beams
19:40:41  <Eddi|zuHause> if you only forwarded UDP protocol, the TCP protocol won't go through
19:41:01  <andythenorth> Wolf01: ?
19:41:05  <Eddi|zuHause> UDP is used for querying the server list, and TCP for the actual game connection
19:41:20  <Wolf01> good one
19:41:29  <Eddi|zuHause> although, usually people misconfigure that the other way around :p
19:43:03  *** Pereba [~UserNick@] has joined #openttd
19:43:36  <Gather> Eddi|zuHause: gah i gotta get some glasses.. i mistyped the destination ip for tcp in firewall config
19:44:29  <Gather> now its working.. now to get it configured with the setup i usually use
20:00:41  *** Zuu [] has joined #openttd
20:06:09  *** andythenorth [] has quit [Ping timeout: 480 seconds]
20:07:37  *** andythenorth [] has joined #openttd
20:15:39  *** andythenorth [] has quit [Ping timeout: 480 seconds]
20:20:30  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
20:27:16  *** sla_ro|master [slamaster@] has quit []
20:29:51  *** Haube [] has quit [Read error: Connection reset by peer]
20:32:33  *** FLHerne [] has joined #openttd
20:51:56  *** Zuu [] has quit [Quit: Leaving]
20:58:08  *** smoke_fumus [~smoke_fum@] has joined #openttd
20:58:10  *** andythenorth [] has joined #openttd
21:12:28  *** andythenorth [] has quit [Quit: andythenorth]
21:47:00  *** Suicyder [~Suicyder@] has quit [Quit:  HydraIRC -> <- The professional IRC Client :D]
21:54:07  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Ping timeout: 480 seconds]
22:20:31  *** frosch [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
22:27:25  *** pxr [] has quit [Quit: Leaving]
22:53:49  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
23:22:09  *** Progman [] has joined #openttd
23:27:26  *** Pereba [~UserNick@] has quit [Quit: ~ AdiIRC - ~]
23:28:08  *** Pulec [] has quit [Ping timeout: 480 seconds]
23:31:17  *** Pulec [] has joined #openttd
23:43:08  *** HerzogDeXtEr [] has quit [Quit: Leaving.]
23:50:45  <Elyon> any issue with me using Alberth's suggestion of `if hasattr('values', value)` instead of `if isinstance(value, Array)`?
23:55:16  *** LadyHawk [] has quit [Read error: Connection reset by peer]
23:55:16  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Read error: Connection reset by peer]
23:55:16  *** LadyHawk [] has joined #openttd
23:55:38  *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
23:58:29  *** oskari89 [] has quit [Read error: Connection reset by peer]

Powered by YARRSTE version: svn-trunk