Times are UTC Toggle Colours
00:02:47 <dreck> sounds like fun :) 00:05:02 *** supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] 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 [~frosch@frnk-5f74435a.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 00:38:19 *** Myhorta[1] [~Myhorta@10.87.37.188.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 01:08:34 *** dreck [~oftc-webi@bas1-ottawa08-1176110546.dsl.bell.ca] has left #openttd [] 03:02:51 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 03:05:35 *** Flygon__ [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 03:08:28 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 03:08:46 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 03:10:52 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 03:26:15 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 03:28:56 *** Flygon__ [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 03:37:25 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 03:43:26 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 03:48:19 *** supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has joined #openttd 03:54:08 *** Biolunar_ [Biolunar@blfd-4d08f50d.pool.mediaWays.net] has joined #openttd 04:01:07 *** Biolunar [Biolunar@blfd-5d821dc4.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 04:16:24 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] 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@179.179.23.201] 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 [~quorzom@cable-78-35-98-177.netcologne.de] 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 [~johekr@p57BD42C3.dip0.t-ipconnect.de] has quit [] 05:56:16 *** Eddi|zuHause [~johekr@p57BD5F96.dip0.t-ipconnect.de] has joined #openttd 06:45:07 *** MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has quit [] 06:59:10 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 06:59:32 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 07:15:19 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Read error: Connection reset by peer] 07:15:51 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd 07:15:52 *** luaduck_zzz is now known as luaduck 07:23:02 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Ping timeout: 480 seconds] 07:45:11 *** liq3 [~liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit [] 07:46:56 <dihedral> greetings 08:04:42 <Supercheese> Salve 08:32:28 *** pxr [~Mychomize@46-236-110-230.customer.t3.se] 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> https://dl.dropboxusercontent.com/u/2651992/Art/Other/Baker%20%26%20Co.%2C%2018th%20Oct%201875.png 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 [~flex@i59F6CCB1.versanet.de] 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 [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds] 09:15:27 *** HerzogDeXtEr [~flex@i59F6CCB1.versanet.de] has quit [Read error: Connection reset by peer] 09:15:55 *** HerzogDeXtEr [~flex@i59F6CCB1.versanet.de] 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 [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Read error: Connection reset by peer] 09:57:55 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd 10:08:44 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Read error: Connection reset by peer] 10:09:18 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd 10:33:42 *** jjavaholic [~jjavaholi@grahamg63.plus.com] 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 [~frosch@frnk-5f740887.pool.mediaWays.net] has joined #openttd 11:30:25 <peter1138> And that was the last we ever heard from Eddi|zuHause... 11:34:36 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has quit [Ping timeout: 480 seconds] 11:35:12 *** supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has joined #openttd 11:36:27 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has joined #openttd 11:46:40 *** sla_ro|master [slamaster@95.76.27.245] has joined #openttd 12:32:33 *** Supercheese is now known as Guest1242 12:32:38 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd 12:38:03 *** Guest1242 [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Ping timeout: 480 seconds] 13:46:16 *** supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] 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@188.35.176.90] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 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@86.92.59.88] 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 [defaultti@lakka.kapsi.fi] 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 [defaultti@lakka.kapsi.fi] 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> https://newgrf-specs.tt-wiki.net/wiki/NML:Spriteset <- 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> https://paste.openttdcoop.org/psr55uqpc 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> https://paste.openttdcoop.org/pvoon5omk 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 [martijn@greed.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 15:47:38 <planetmaker> hm... 15:52:29 *** TheMask96 [martijn@wrath.vhost.ne2000.nl] has joined #openttd 15:52:45 <planetmaker> https://paste.openttdcoop.org/p8wqrxkgf <-- 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 [~Mychomize@46-236-110-230.customer.t3.se] 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 [~Myhorta@00018fad.user.oftc.net] 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> https://paste.openttdcoop.org/pqvoezwke <-- 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 [~quorzom@cable-78-35-98-177.netcologne.de] 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:https://paste.openttdcoop.org/pbyx7xrcu (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> https://paste.openttdcoop.org/pc8ozzfzv <-- 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> https://paste.openttdcoop.org/pzuzoxvd6 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: http://miranda-im.org] 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> https://dev.openttdcoop.org/issues/2746#note-6 <- see second line 16:29:22 <Elyon> frosch123, mind if I post https://paste.openttdcoop.org/plpgunpow 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: http://dev.openttdcoop.org/issues/2746#note-7 <- 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 [~frosch@frnk-4d019ede.pool.mediaways.net] 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 [~frosch@frnk-5f740887.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 17:16:06 *** MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] 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 [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] 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 [~T@taedewerkhoven.co.uk] has quit [Ping timeout: 480 seconds] 17:37:09 *** Taede [~T@nurionis.co.uk] has joined #openttd 17:47:24 *** quorzom_ [~quorzom@cable-78-35-98-177.netcologne.de] has joined #openttd 17:47:30 *** quorzom [~quorzom@cable-78-35-98-177.netcologne.de] has quit [Read error: Connection reset by peer] 17:47:30 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer] 17:47:44 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has joined #openttd 17:53:46 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 17:53:49 *** mode/#openttd [+v glx] by ChanServ 17:55:37 *** Progman [~progman@p57A18790.dip0.t-ipconnect.de] has joined #openttd 18:26:11 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd 18:26:17 *** gelignite [~gelignite@i528C3ACD.versanet.de] has joined #openttd 18:30:16 *** Biolunar_ [Biolunar@blfd-4d08f50d.pool.mediaWays.net] 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 [~flex@i59F6CCB1.versanet.de] has quit [Read error: Connection reset by peer] 18:37:56 *** HerzogDeXtEr [~flex@i59F6CCB1.versanet.de] 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_ [~quassel@200-161-120-132.dsl.telesp.net.br] has quit [Remote host closed the connection] 18:59:12 *** oyvind [~oyvind@vmnet.devitpro.com] 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 [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 19:13:20 <andythenorth> o/ 19:21:15 *** Progman [~progman@p57A18790.dip0.t-ipconnect.de] 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 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] 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 [~wolf01@host44-14-dynamic.31-79-r.retail.telecomitalia.it] 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: ? http://www.eurobricks.com/forum/index.php?showtopic=65776 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@179.179.23.201] 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 [~Zuu@h-114-162.a98.priv.bahnhof.se] has joined #openttd 20:06:09 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Ping timeout: 480 seconds] 20:07:37 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 20:15:39 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] 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@95.76.27.245] has quit [] 20:29:51 *** Haube [~Michi@ip25048c11.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] 20:32:33 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd 20:51:56 *** Zuu [~Zuu@h-114-162.a98.priv.bahnhof.se] has quit [Quit: Leaving] 20:58:08 *** smoke_fumus [~smoke_fum@188.35.176.90] has joined #openttd 20:58:10 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 21:12:28 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 21:47:00 *** Suicyder [~Suicyder@86.92.59.88] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- 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 [~frosch@frnk-4d019ede.pool.mediaways.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 22:27:25 *** pxr [~Mychomize@46-236-110-230.customer.t3.se] has quit [Quit: Leaving] 22:53:49 *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd 23:22:09 *** Progman [~progman@p57A18790.dip0.t-ipconnect.de] has joined #openttd 23:27:26 *** Pereba [~UserNick@179.179.23.201] has quit [Quit: ~ AdiIRC - www.adiirc.com ~] 23:28:08 *** Pulec [pulec@unaffilated.amunak.net] has quit [Ping timeout: 480 seconds] 23:31:17 *** Pulec [pulec@unaffilated.amunak.net] has joined #openttd 23:43:08 *** HerzogDeXtEr [~flex@i59F6CCB1.versanet.de] 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 [~LadyHawk@5751e87a.skybroadband.com] 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 [~LadyHawk@5751e87a.skybroadband.com] has joined #openttd 23:55:38 *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd 23:58:29 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has quit [Read error: Connection reset by peer]