Times are UTC Toggle Colours
00:03:46 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has quit [Quit: There's a real world out here!] 00:12:04 *** Zeetherdroid [~AndChat68@user-0c6t3g5.cable.mindspring.com] has quit [Quit: Bye] 00:31:13 *** smoke_fumus|2 [~smoke_fum@188.35.176.90] has joined #openttd 00:31:13 *** smoke_fumus [~smoke_fum@188.35.176.90] has quit [Read error: Connection reset by peer] 00:32:52 *** smoke_fumus|2 [~smoke_fum@188.35.176.90] has quit [] 00:35:30 *** smoke_fumus [~smoke_fum@188.35.176.90] has joined #openttd 00:59:09 *** HerzogDeXtEr [~flex@i59F6B664.versanet.de] has quit [Quit: Leaving.] 01:19:05 <mgrunin> openttd is shit 01:19:23 <mgrunin> how autistic do you need to be 01:20:52 <Elyon> wow, two insults in as many lines 02:01:36 *** luaduck_zzz is now known as luaduck 02:08:43 *** MJP_ [~mjp@hq.z77.fr] has quit [Ping timeout: 480 seconds] 02:16:58 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 02:20:32 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 02:26:03 *** DabuYu [DabuYu@128.250.79.238] has quit [] 02:29:30 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 02:30:17 *** DabuYu [DabuYu@128.250.79.238] has quit [] 02:33:14 *** quorzom_ [~quorzom@cable-78-35-98-177.netcologne.de] has quit [Remote host closed the connection] 02:38:42 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 03:08:35 <Elyon> am I correct in assuming that to define my own property for nml, I am supposed to build an expression tree? 03:11:29 <Elyon> that eventually coalesces down to a constant string of bytes? 03:16:55 <Elyon> in that case, I am having some issues with `expression.ConstantNumeric(0x42D + 0x80000000)` seemingly rendering as negative (which makes sense considering it as a 32bit integer) 03:17:54 <Elyon> still, reduce() spits out a 32bit integer which is unfortunate as I have way more than 32 bits 03:21:13 <Elyon> it spits out the 24 low bits correctly, and then the high ~120 bits incorrectly 03:21:22 <Elyon> or not at all, as it were 03:21:48 <Elyon> (the negativity thing is not an issue apparently) 03:24:20 <Elyon> ooooh 03:24:32 <Elyon> nevermind all of that, I should have read the Action0Property comments 03:24:35 <Elyon> d'oh 03:24:58 <Elyon> for what it's worth, here's what I ended up with before realising my mistake: ((((((((((((((((((2 | (1012 << 8)) | (0 << 16)) | (-2147482579 << 24)) | (0 << 32)) | (0 << 40)) | (0 << 48)) | (0 << 56)) | (16 << 64)) | (4 << 72)) | (50 << 80)) | (-2147482579 << 88)) | (0 << 96)) | (0 << 104)) | (12 << 112)) | (0 << 120)) | (16 << 128)) | (4 << 136)) | (50 << 144)) 03:25:19 * Elyon is monologuing until someone wakes up 03:35:34 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 03:35:56 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 03:53:44 *** Flygon__ [~Flygon@218.214.18.147] has joined #openttd 03:56:23 *** Biolunar [Biolunar@blfd-4d08f76f.pool.mediaWays.net] has joined #openttd 03:56:34 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 03:56:56 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 03:59:41 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 04:03:21 *** Biolunar_ [Biolunar@blfd-4db030eb.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 04:23:53 *** avdg [~avdg@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:23:56 *** ^Spike^ [~Spike@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:24:44 <Elyon> hmm 04:24:58 *** Hirundo [~Hirundo@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:25:03 *** Osai [~Osai@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:25:04 *** V453000 [~V453000@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:25:33 *** XeryusTC [~XeryusTC@000128e4.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:25:39 *** Yexo [~Yexo@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:25:43 *** fonsinchen [~fonsinche@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:25:50 *** tneo [~tneo@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:27:26 *** Hirundo [~Hirundo@188.cimarosa.openttdcoop.org] has joined #openttd 04:27:26 *** ^Spike^ [~Spike@188.cimarosa.openttdcoop.org] has joined #openttd 04:27:26 *** Osai [~Osai@188.cimarosa.openttdcoop.org] has joined #openttd 04:27:30 *** Terkhen [~Terkhen@0001612d.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:27:39 *** planetmaker [~planetmak@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:27:44 *** Hazzard [~Hazzard@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 04:27:56 *** XeryusTC [~XeryusTC@000128e4.user.oftc.net] has joined #openttd 04:28:26 *** Yexo [~Yexo@188.cimarosa.openttdcoop.org] has joined #openttd 04:28:26 *** avdg [~avdg@188.cimarosa.openttdcoop.org] has joined #openttd 04:28:56 *** planetmaker [~planetmak@188.cimarosa.openttdcoop.org] has joined #openttd 04:28:56 *** tneo [~tneo@188.cimarosa.openttdcoop.org] has joined #openttd 04:28:59 *** mode/#openttd [+o planetmaker] by ChanServ 04:29:26 *** Hazzard [~Hazzard@188.cimarosa.openttdcoop.org] has joined #openttd 04:30:26 *** V453000 [~V453000@188.cimarosa.openttdcoop.org] has joined #openttd 04:30:26 *** Terkhen [~Terkhen@0001612d.user.oftc.net] has joined #openttd 04:30:29 *** mode/#openttd [+o Terkhen] by ChanServ 04:30:57 *** fonsinchen [~fonsinche@188.cimarosa.openttdcoop.org] has joined #openttd 04:58:51 *** MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has quit [] 05:32:58 *** supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has joined #openttd 05:56:01 *** Eddi|zuHause [~johekr@p5DC67E7C.dip0.t-ipconnect.de] has quit [] 05:56:16 *** Eddi|zuHause [~johekr@p5DC67064.dip0.t-ipconnect.de] has joined #openttd 06:16:13 *** fkinglag1 [~fkinglag@c-66-41-55-107.hsd1.mn.comcast.net] has quit [Ping timeout: 480 seconds] 06:34:50 *** smoke_fumus [~smoke_fum@188.35.176.90] has quit [Read error: Connection reset by peer] 06:49:59 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 06:50:21 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 06:59:29 *** fkinglag [~fkinglag@c-66-41-55-107.hsd1.mn.comcast.net] has joined #openttd 07:26:56 *** _hsknz [~hsknz@119.224.20.201] has quit [Quit: :)] 07:35:08 *** HerzogDeXtEr [~flex@88.130.163.61] has joined #openttd 07:35:27 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit [] 07:47:02 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 08:00:35 <V453000> heyooooo 08:00:42 <V453000> where can I find a list of all the land tiles? 08:00:59 <V453000> like which IDs is snow 1-asdf, which IDs is rough tiles, ... 08:01:44 <Elyon> supposedly http://mz.openttdcoop.org/opengfx/authors/script.php?feature=spritesbyfile but I can't connect 08:02:36 <V453000> yeah mz is probably down 08:05:15 <V453000> guess opengfx+ landscape is best thing I could get atm 08:24:57 *** Yotson [~Yotson@2001:980:6ac8:1:c109:6eb9:2e41:3b6] has joined #openttd 08:31:58 *** Memphis[zZz] [~Memphisau@58-7-204-127.dyn.iinet.net.au] has joined #openttd 09:04:11 *** supermop [~supermop@d110-33-179-139.sun801.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds] 09:11:06 *** Nothing4You [N4Y@nothing4you.w.tf-w.tf] has joined #openttd 09:12:07 *** tokai|mdlx [~tokai@port-92-195-2-171.dynamic.qsc.de] has quit [Quit: c('~' )o] 09:14:40 *** tokai [~tokai@00012860.user.oftc.net] has joined #openttd 09:14:43 *** mode/#openttd [+v tokai] by ChanServ 09:19:26 *** Memphis[zZz] is now known as BlueSteel 09:23:37 *** gelignite [~gelignite@i528C339B.versanet.de] has joined #openttd 09:46:25 *** MJP [~mjp@hq.z77.fr] has joined #openttd 10:04:45 <dihedral> hello 10:05:42 <Elyon> hiya 10:06:46 *** Sheogorath [~madgod@0001f8ef.user.oftc.net] has quit [Remote host closed the connection] 10:09:06 *** Sheogorath [~madgod@0001f8ef.user.oftc.net] has joined #openttd 10:15:33 <BlueSteel> greetings 10:16:10 *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Ping timeout: 480 seconds] 10:38:00 *** gelignite [~gelignite@i528C339B.versanet.de] has quit [Quit: http://bit.ly/nkczDT] 11:09:15 <V453000> H Y 11:30:28 <Elyon> H I 11:50:19 *** Marshy [~oftc-webi@212.50.186.227] has joined #openttd 11:50:51 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has joined #openttd 12:07:04 *** sla_ro|master [slamaster@95.76.27.245] has joined #openttd 12:12:16 *** gelignite [~gelignite@i528C339B.versanet.de] has joined #openttd 12:26:27 *** Jinassi [~jinassi@0001ec72.user.oftc.net] has joined #openttd 12:29:52 *** LadyHawk [~LadyHawk@5751e87a.skybroadband.com] has quit [] 12:30:20 *** LadyHawk [~LadyHawk@5751e87a.skybroadband.com] has joined #openttd 12:33:15 *** Supercheese is now known as Guest1019 12:33:20 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd 12:38:01 *** Guest1019 [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Ping timeout: 480 seconds] 12:51:32 *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 12:52:57 *** Marshy [~oftc-webi@212.50.186.227] has quit [Remote host closed the connection] 13:08:31 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has quit [Ping timeout: 480 seconds] 13:09:47 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has joined #openttd 13:11:32 *** Jinassi [~jinassi@0001ec72.user.oftc.net] has quit [Quit: Nettalk6 - www.ntalk.de] 13:22:34 *** LadyHawk [~LadyHawk@5751e87a.skybroadband.com] has quit [] 13:23:05 *** LadyHawk [~LadyHawk@5751e87a.skybroadband.com] has joined #openttd 13:35:21 *** Suicyder [~Suicyder@86.92.59.88] has joined #openttd 13:36:01 *** Jinassi [~jinassi@176-76-115-200.ipv4.mobile.tusmobil.si] has joined #openttd 13:44:38 *** engineerwolf [~engineerw@0001f8e6.user.oftc.net] has joined #openttd 13:48:14 *** Jinassi [~jinassi@0001ec72.user.oftc.net] has quit [Quit: Nettalk6 - www.ntalk.de] 13:52:47 *** engineerwolf [~engineerw@0001f8e6.user.oftc.net] has quit [Quit: Leaving] 14:00:34 *** Jinassi [~jinassi@176-76-115-200.ipv4.mobile.tusmobil.si] has joined #openttd 14:00:46 *** Jinassi [~jinassi@0001ec72.user.oftc.net] has left #openttd [] 14:04:36 <Eddi|zuHause> i guess we can now add this to the long list of date formats :p http://img.pr0gramm.com/2015/01/07/d13baf262cf11502.jpg 14:06:33 <peter1138> Err 14:08:13 <Eddi|zuHause> (do i have to explain the joke?) 14:09:03 <V453000> XD 14:10:39 <peter1138> German / Brazil / 15 14:10:43 <peter1138> +y 14:12:49 <Eddi|zuHause> that is not really the joke :) 14:13:13 <V453000> Germany sent 7 nuclear bombs to 1 brazil last year 14:13:36 <__ln___> peter1138: i think it's related to the sport where adult men run across a grass field and try to kick a ball. 14:13:38 <V453000> brazil was morally devastated because they could collect just one 14:14:00 <V453000> it is, fuck football, huzzah 14:27:02 <Eddi|zuHause> __ln___: there are not a lot of sports that don't fit the pattern "adult {men,women} {run,walk,jump,swim}-ing across a {grass,concrete,dirt,wood,water} {field,floor,basin} trying to {kick,hit,throw} a ball 14:29:40 *** frosch123 [~frosch@frnk-4d01bf38.pool.mediaWays.net] has joined #openttd 14:30:09 <Belugas> hello 14:31:16 <frosch123> hello sir belugas :) 14:31:27 <__ln___> Eddi|zuHause: counter examples: chess; brockian ultra-cricket 14:32:11 <Eddi|zuHause> cricket doesn't involve walking and a ball? 14:32:54 <__ln___> the usual cricket probably, but brockian ultra-cricket is a bit different. 14:33:12 <peter1138> badminton 14:33:15 <__ln___> http://hitchhikers.wikia.com/wiki/Brockian_Ultra-Cricket 14:33:29 <peter1138> ice hockey 14:33:39 <peter1138> archery 14:33:41 <b_jonas> tennis on a plastic field 14:33:54 <peter1138> boxing 14:34:05 <peter1138> rowing 14:34:10 <peter1138> cycling 14:34:25 <peter1138> bobsled 14:34:32 <peter1138> skiing 14:34:42 <planetmaker> sailing 14:34:51 <planetmaker> chess :P 14:35:06 <Eddi|zuHause> ice hockey: the puck is (roughly) a ball. 14:35:27 <Eddi|zuHause> archery: the target is (roughly) a ball, alternately, the arrow is (roughly) a ball 14:35:32 <peter1138> ... 14:35:40 <Eddi|zuHause> boxing: the opponent's head is (roughly) a ball 14:35:49 <SpComb> climbing 14:35:56 <Eddi|zuHause> rowing: not entirely sure :p 14:36:31 <SpComb> the boat is roughly a ball? 14:37:02 <Eddi|zuHause> i suppose the finish line is roughly a ball :p 14:37:02 <__ln___> rowing moves H2O atoms, which are roughly balls 14:37:19 <Belugas> yoho sir frosch123 :) 14:37:38 <Eddi|zuHause> and chess has 32 roughly balls on a paper field 14:37:54 <Eddi|zuHause> and moving your arm is (roughly) running/walking :p 14:38:32 <Belugas> computers. keys are roughly balls. fingertips are roughly balls. eyesball are... balls 14:39:11 <peter1138> balls are balls 14:40:26 <planetmaker> ho, sir belugas! 14:41:56 <Belugas> planets are balls. buwhahahah!! 14:42:04 <Belugas> hello planetmaker :) 14:42:05 <V453000> BALLS OF STEEL 14:42:07 <V453000> hello everybody 14:42:18 <Belugas> Balls To the Wall! 14:42:33 <Belugas> (that is for the old head bangers around here ;) ) 14:42:41 <b_jonas> trains are roughly balls 14:43:22 <Belugas> "My hands felt just like two BALLoons" 14:45:04 <planetmaker> if planets weren't balls, they wouldn't be planets by definition ;) 14:46:16 <Eddi|zuHause> V453000: more like balls of iron and nickel, with a few bits of other stuff as coating 14:47:48 <Eddi|zuHause> planetmaker: doesn't everything with sufficient mass automatically form into some ball shape? 14:49:23 *** smoke_fumus [~smoke_fum@188.35.176.90] has joined #openttd 14:50:16 <planetmaker> Eddi|zuHause, yes, that's why 14:50:33 <planetmaker> if it's too small to form a ball-shape, it's by definition not a planet anymore 14:51:07 <planetmaker> (but possibly a dwarf planet, asteroid, comet, whatever...) 14:51:26 <Eddi|zuHause> well, there are certainly ball shaped dwarf planets :) 14:51:28 <frosch123> aren't they all elipsoids? 14:51:32 <frosch123> due to rotation? 14:52:04 <planetmaker> yes. But that's true for balls, too, to a similar degree :) 14:52:05 <Eddi|zuHause> frosch123: there are tidal forces and stuff 14:53:05 <V453000> BALLS OF STEEL REGARDLESS 14:53:26 <Eddi|zuHause> frosch123: the exact shape of the geoid is a very very lengthy and afaik still ongoing discussion 14:53:54 <Eddi|zuHause> frosch123: that's why the GPS doesn't say 0° if you stand on the 0° line in greenwich 14:54:10 <Eddi|zuHause> because the brits use a different geoid than the americans 14:54:10 <planetmaker> Eddi|zuHause, not really. But as with every changing thing, it's good to update stuff occasionally. Or measure more accurately 14:54:53 <planetmaker> it's just the equi-potential surface taken at sea level. "just" :P 14:55:31 <planetmaker> thus it's already difficult when measured on land... you have to account for the (partially) unknown ground below you 14:56:22 <peter1138> Oh, XMBC was renamed. 14:56:29 <Eddi|zuHause> planetmaker: yes, but every country naturally had better/finer measurement for their own area than the area elsewhere on the planet, thus their model of the geoid was better for them 14:57:09 <Eddi|zuHause> and unifying those is probably a weird political thing 14:57:42 <planetmaker> not really that much 14:58:05 <planetmaker> more political is what's on the surface 14:58:13 <planetmaker> but that's of no interest for the geoid 14:58:51 <b_jonas> Eddi|zuHause: like, the political leaders play "you mama so fat it makes the geoid flatter near your country" with each other? 14:59:44 <planetmaker> it actually wouldn't make it flatter but more pointy-shaped ;) 15:00:32 <Eddi|zuHause> b_jonas: more like "why would we accept a geoid that would have us move the hill with our observatory, which we used as reference point, like, forever, by 200m?" 15:08:07 *** TheMask96 [martijn@sloth.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 15:13:18 *** TheMask96 [martijn@wrath.vhost.ne2000.nl] has joined #openttd 15:37:05 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has joined #openttd 15:54:40 *** quorzom [~quorzom@cable-78-35-98-177.netcologne.de] has joined #openttd 16:01:50 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has quit [Ping timeout: 480 seconds] 16:03:29 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has joined #openttd 16:04:27 <Elyon> hiya 16:06:10 <Elyon> frosch123: thanks to your suggestion of leveraging nml, I now have this: http://files.elyon.net/teaser.png 16:07:18 <dihedral> congratulations... you built a station? 16:07:26 <Elyon> yes 16:07:34 <Elyon> a custom station. In NML. 16:08:01 <Elyon> rudimentary, of course, but small moves :) 16:08:06 <dihedral> custom, because you used the same tile over and over again? 16:08:13 <dihedral> s/tile/sprite/ 16:09:05 <dihedral> yes, small steps at a time ;-) 16:09:32 <Eddi|zuHause> ... it's a dihedral. how did that happen? 16:09:47 <dihedral> must have been a glitch in the matrix 16:09:49 <Elyon> custom in that it's a station newgrf 16:10:40 <Elyon> with a custom (yet identical) layout to the most basic platform, it's ... rargh 16:10:55 <Elyon> the teaser is the code, not the station! 16:11:20 <dihedral> the teaser is the link, not the picture :-P 16:11:28 <Elyon> touché 16:11:31 <dihedral> :-D 16:11:32 <Eddi|zuHause> Elyon: a propos stations, we've been looking for someone who would recode the MTSS set, because the existing implementation has a weird license (the graphics are fine) 16:11:48 <Elyon> MTSS? 16:12:03 <Eddi|zuHause> modern train stations set 16:12:09 <Eddi|zuHause> by red*star 16:12:14 <dihedral> sounds like a syndrome if you ask me 16:12:20 <Elyon> and I'm working on CATS, which has taken me to working on leveraging nml. So, NML then CATS then who knows? :D 16:12:27 <dihedral> modern train station syndrom 16:12:29 <Elyon> what's with the license? 16:12:36 <Elyon> :D 16:12:49 <Eddi|zuHause> Elyon: was something weird like "ask me before you modify it" 16:12:56 <Elyon> oh, one of those 16:12:58 <dihedral> CATS -> cought another train syndrome 16:13:03 <Elyon> XD 16:13:13 <Elyon> Eddi|zuHause: but what about the graphics? 16:13:18 <Elyon> that's just redistribution or? 16:13:27 <Eddi|zuHause> Elyon: they're beautiful, but cumbersome to build 16:13:36 <Eddi|zuHause> Elyon: needs better structure/handling 16:13:36 <Elyon> mm :) 16:13:51 <Eddi|zuHause> and more flexibility 16:14:06 <Elyon> I see! 16:14:18 <Eddi|zuHause> i have made a plan somewhere, but it's probably in the german forum 16:14:20 <Elyon> and I presume some form of free software license is what you had in mind? 16:14:51 <Eddi|zuHause> yes. either GPL or CC-BY-SA 16:15:15 <Elyon> supposedly CC licenses aren't intended for code 16:15:35 <Elyon> or software, as it were 16:15:45 <Eddi|zuHause> yes, has some problems 16:15:56 <Elyon> although I have released many a source with CC-BY in the past 16:15:58 <Eddi|zuHause> but people around here are usually "nice" anyway 16:16:07 <Elyon> mhm :D 16:16:11 <Elyon> I've noticed 16:16:24 <dihedral> "nice" ... used thoe quotationmarks by accident did we? 16:17:04 <Eddi|zuHause> *cough* all things canadian *cough* 16:17:05 <Elyon> NICE: intentionally cynical expectations 16:17:07 <dihedral> so which one of the guys you've met adds reason for the quotation amrks then? 16:17:48 <dihedral> Belugas, I am sure it was Belugas ... though they other odd guy was TrueBrain :-P 16:17:56 <Eddi|zuHause> or people that rage-quit the community, like richk 16:18:06 <dihedral> pfft 16:18:19 <dihedral> i prefer those who got kicked ... like yorick 16:18:25 <Eddi|zuHause> dihedral: you probably missed the canadian bit, about half a year ago 16:18:33 <dihedral> probably 16:18:41 <Belugas> yorick... yurk 16:18:45 <Belugas> baddd memories 16:18:46 <dihedral> must i search the logs? 16:18:51 <Belugas> yo dihedral :) 16:18:53 <dihedral> sorry Belugas 16:18:55 <Elyon> logs schmogs 16:18:59 <dihedral> hey ho sir 16:19:12 <dihedral> how's the kid doing? 16:19:14 <Belugas> how is new year starting for you? 16:19:18 <dihedral> must be something like 9 now? 16:19:23 <Belugas> 11 ;) 16:19:31 <dihedral> wow - i was away for a bit! 16:19:46 <Belugas> he's going well, about to get a fine young man 16:19:48 <Belugas> like his dad 16:19:51 <Belugas> buwhahaha!!!! 16:19:56 <Eddi|zuHause> dihedral: there was a guy, that made canadian grfs, and believed that all GRF-IDs starting with "CA" are HIS and ONLY HIS. which caused... issues... 16:20:01 <dihedral> you are 11? you look much older, you know :-D 16:20:18 <Belugas> yeah... life ruined me 16:20:23 <dihedral> Eddi|zuHause: that is hillarious 16:20:26 <Belugas> or rather... i ruined my lofe ;) 16:20:28 <Elyon> wha... what? 16:20:29 <Eddi|zuHause> ... and then he replaced all bananas versions of his GRFs with some with scrambled graphics 16:20:39 <Eddi|zuHause> ... and rage-quit 16:21:22 <Elyon> smooth 16:21:32 <dihedral> https://www.youtube.com/watch?v=hT_8CiLw85w 16:22:09 <dihedral> Belugas: now what makes you say stuff like that? 16:22:25 <dihedral> Eddi|zuHause: lovely! that's the way forward... 16:22:35 <dihedral> was there not another guy in the forums who did that? 16:22:50 <Belugas> because... i was a bad boy ? 16:23:08 <dihedral> what kind of misschif did you get youself into this time? 16:23:35 <Eddi|zuHause> dihedral: there was someone who quit the forum, and replaced all his posts he ever made with "..." 16:23:43 <Eddi|zuHause> dihedral: which was actually the same person :) 16:23:51 <Elyon> by the way, regarding commits; it seems to me that looong commits that fully implement a feature/change is preferred? 16:24:20 <Eddi|zuHause> Elyon: not really 16:24:22 <dihedral> Eddi|zuHause: there was another guy 16:24:34 <Sacro> mm, old skool peeps 16:24:35 <Eddi|zuHause> dihedral: there are lots of guys. you need to be more specific 16:25:06 <Elyon> Eddi: oh, hmm. Actually now that you mention it, NML commits are spread merely minutes apart. Noted, thanks! 16:25:08 * dihedral checks the forums 16:25:10 <Eddi|zuHause> Elyon: in the end, it's about your style, but generally it's recommended that commits be smaller, more atomic 16:25:19 <Elyon> that's what I'm used to as well 16:25:38 <dihedral> where's the winter theme!! 16:25:49 <Eddi|zuHause> dihedral: in the forum settings 16:25:56 <dihedral> pffft 16:26:31 <Eddi|zuHause> some person complained too much about the winter theme destroying his eyes, so a setting to turn it off was introduced :p 16:26:34 <peter1138> 1 character at a time 16:26:50 <Elyon> haha 16:27:40 <Eddi|zuHause> that might have been a person taking part in this conversation :p 16:28:16 <Belugas> me? 16:28:18 <Belugas> naaaaaa... 16:28:24 <Elyon> bind 'hg add . && hg commit -m `date`' to :write 16:28:31 <Belugas> i hate snow but not to that extend 16:28:33 <dihedral> muxy 16:28:35 <dihedral> that's the guy 16:28:38 <Eddi|zuHause> no. you complain about real snow :p 16:29:23 <Eddi|zuHause> even though you live more southern than most of us :p 16:29:27 <Belugas> yeahyeahyeahyeahyeah 16:29:44 <Belugas> shitty white stuff 16:29:53 <Belugas> no good doing 16:29:54 <dihedral> we had snow this winter - and i still have a can full of instant snow 16:30:13 <Eddi|zuHause> dihedral: i don't remember what that was about. 16:30:17 <Belugas> lol... you "had" ! 16:30:19 <Belugas> lovely 16:30:23 *** Jinassi [~jinassi@176.76.115.200] has joined #openttd 16:30:47 <dihedral> muxy got banned after that, got furious for something, and started editing all his posts into '...' 16:30:58 <Eddi|zuHause> oh, that was the "we hate rubidium, because he fixed the security holes we abused" community? 16:31:13 <dihedral> and above all else, there is luukland 16:31:23 <Eddi|zuHause> yeah. that i meant 16:31:23 <Belugas> mmmh.. not sure about that one Eddi|zuHause 16:31:29 <dihedral> hihihi 16:31:45 <Eddi|zuHause> muxy and luukland were somehow closely involved with each other 16:32:23 <dihedral> lol 16:32:29 <Eddi|zuHause> no, but the name i was trying to not say was "OzTrans" 16:32:31 <dihedral> and yorick wrote their patches 16:32:43 *** TheMask96 [martijn@wrath.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 16:37:19 *** TheMask96 [martijn@greed.vhost.ne2000.nl] has joined #openttd 16:39:54 <NGC3982> I'm trying to learn myself to use entry-exit 16:39:55 <NGC3982> http://i.imgur.com/MnBnNxl.png 16:40:26 <NGC3982> I want the train waiting closest to the station, to simply continue on the outer most empty track if the station is full 16:40:33 <Eddi|zuHause> why would you do that? 16:41:22 <NGC3982> I want it to continue traveling instead of waiting, not blocking the drop-off trains. 16:41:44 <Eddi|zuHause> basically, the "firstred exit penalty" must be larger than the penalty for a whole roundtrip 16:42:00 <Eddi|zuHause> default value is 10000, i think 16:42:04 <Eddi|zuHause> so 100 tiles 16:43:16 <dihedral> crossings over roads add penalty IIRC 16:45:36 *** luaduck is now known as luaduck_zzz 16:45:52 <Belugas> i think i love tropical screenshots... 16:47:32 <peter1138> I prefer tropical photos. 16:48:19 <Eddi|zuHause> i'd settle for subtropic vacations 16:49:00 <Belugas> me too, peter1138! But... i have to wait a bit for my next ones ;) 16:49:08 <Eddi|zuHause> ... preferably avoiding greek ferries and asian flights 16:49:12 <Belugas> welll.. a bit... less then 3 months now! 16:58:45 <frosch123> Elyon: i see, you are not taking the short route :) 16:59:08 <frosch123> Elyon: the prediminant method for additions here are "mercurial queues" 16:59:22 <frosch123> they result in closesy consecutive commits 16:59:41 <frosch123> mq somehow invents the commit time depending on the patch size or something 16:59:45 <frosch123> but maybe it is just random 17:00:06 <Elyon> okay hmm 17:00:53 <Elyon> frosch123: the 'patching nml to support stations' route seemed shorter than the 'formatting all my data so nml will eat it' route :D 17:01:34 <frosch123> i thought one could just write the hex bytes into some baseaction 17:01:58 <frosch123> but well, if you can use even more nml, you can also use the lang files :) 17:02:10 <Elyon> indeed! 17:02:29 <Elyon> although not really that useful for stations as they're (as far as I can tell) untranslated 17:02:36 <frosch123> also, if you need some repo on the devzone: we already have eddi-nml, so there can also be a elyon-nml :po 17:02:46 <Elyon> frosch123: :D :D 17:02:56 <Elyon> from where I could supply pull requests? 17:03:00 <Elyon> eventually, anyway 17:03:12 <Elyon> or at the very least reference commits in NML issue tracker 17:03:17 <frosch123> everyone is here anyway 17:06:52 <Elyon> hmm, now, what degree of atomicity should I apply - one commit for each implemented station item property, or one commit for all of them? 17:07:16 <Elyon> (except spritelayout as that deserves its own commit either way) 17:07:33 <frosch123> whatever suits you, and is easy to read 17:08:24 <Elyon> I'm just worried about if my changes were to (despite all odds) be applied to the main repo, whether I'll bloat the revision history for a while 17:09:00 <Elyon> s/I'll/it'll 17:09:02 <frosch123> as said, we use mercurial queues, we change history all the time 17:09:18 <Elyon> hmm, I'll have to read up on that 17:11:33 <Elyon> ah, that's neat 17:11:43 <Eddi|zuHause> basically, with mq you work on a "secondary" repository, and once you're finished, you import those changes into the main repository, then push 17:11:52 <Elyon> so it's basically mini revision history as a patchset? 17:12:05 <frosch123> it's a "history draft" :p 17:12:16 <Eddi|zuHause> yes, the patches are what you want your commits in the end to look like 17:12:17 <Elyon> I usually just use branches for that 17:12:18 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd 17:12:24 <frosch123> if you notice a bug, you fix it in the original commit instead of adding a fix-commit 17:12:25 <Eddi|zuHause> but you can go back and forth through the patches while you work 17:12:46 <Elyon> ooh 17:12:48 <Elyon> that's neat 17:12:52 <frosch123> you can move changes between commits 17:12:57 <frosch123> reorder commits 17:13:11 <Elyon> so only after you're done implementing a full changeset (with revisions to the uh, revisions) fully you push? 17:13:12 <frosch123> some people call it "searching for the perfect patch series" 17:13:19 <Elyon> haha :D 17:13:22 <Elyon> I approve 17:13:39 * Elyon `hg rollback`s 17:13:49 <frosch123> usually we discuss it, and tear each others patches apart :p 17:13:58 <frosch123> Elyon: hg qimport 17:14:01 <Elyon> that's what you do with pull requests anyway! 17:14:21 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit [Ping timeout: 480 seconds] 17:14:29 <Elyon> qimport => ? 17:14:53 <frosch123> convert already committed stuff into mq patches 17:16:38 *** Buntunub [~quassel@c-24-126-85-103.hsd1.va.comcast.net] has quit [Ping timeout: 480 seconds] 17:17:29 <Elyon> oh that's neat. But I've started from scratch with the intent of actually supplying a hopefully possibly sensible patchset 17:18:00 <frosch123> that's also fine :) 17:21:47 <Elyon> mq is a perfectionist's wet dream/night terror 17:22:49 <Elyon> so anyway, to recap: I just `hg qnew <short-name>` repeatedly to generate multiple patches, each to-be-perfected? 17:23:58 <frosch123> yes, with -m you can also add a commit message 17:24:10 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has joined #openttd 17:24:13 <frosch123> with qpush and qpop you can move the working copy 17:24:27 <frosch123> if not applied you can also edit the patch files directly in .hg/patches 17:24:35 <frosch123> esp. to edit commit messages 17:24:35 <Elyon> amazing 17:24:39 *** MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has joined #openttd 17:24:43 <frosch123> or if you like to also split or merge patches 17:25:12 <frosch123> i have heard of a more modern "hg evolve" extension, but i am not aware of anyone here using it 17:25:14 <Elyon> I will definitely be learning this mq 17:25:37 <Elyon> version control control system 17:26:25 <frosch123> in theory the patches are in a repository themself: ".hg/patches" is a repository 17:26:46 <frosch123> so you can in theory save and restore previous patch versions, but i had never had a use case for that :p 17:27:09 <Elyon> vcccs 17:27:10 <frosch123> finally there are hg qimport and hg qfinish to commit and un-commit stuff 17:27:21 <frosch123> i think that's about all :p 17:27:28 <Elyon> seems powerful and useful 17:37:13 <Eddi|zuHause> i've never quite got around to it 17:37:27 <Eddi|zuHause> it's something that makes your work more annoying for a while until you are fluent with it 17:39:15 *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd 17:39:18 *** mode/#openttd [+o Alberth] by ChanServ 17:43:46 *** Jinassi [~jinassi@0001ec72.user.oftc.net] has quit [Ping timeout: 480 seconds] 17:45:27 <DorpsGek> Commit by translators :: r27115 trunk/src/lang/irish.txt (2015-01-07 17:45:20 UTC) 17:45:28 <DorpsGek> -Update from WebTranslator v3.0: 17:45:29 <DorpsGek> irish - 10 changes by tem 17:51:16 <Sacro> \o/ 17:55:04 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd 18:03:44 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 18:03:47 *** mode/#openttd [+v glx] by ChanServ 18:20:28 *** Jinassi [~jinassi@176-76-115-200.ipv4.mobile.tusmobil.si] has joined #openttd 18:20:35 *** Jinassi [~jinassi@0001ec72.user.oftc.net] has left #openttd [] 18:26:21 *** Progman [~progman@p57A181F6.dip0.t-ipconnect.de] has joined #openttd 18:31:59 *** Pereba [~UserNick@177.17.86.11] has joined #openttd 18:40:53 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 18:41:40 <andythenorth> o/ 18:41:46 <Elyon> o/ 18:42:11 <V453000> heyoo 18:47:16 <planetmaker> frosch123, when using mq, the patches are *not* in a repository themselves. That exactly is the danger / problem with mq. They are only in a repo themselves, when you hg init the .hg/patches directory 18:47:33 <planetmaker> and then actually make use of that and regularily check in the patches 18:47:37 <frosch123> afaik that is the default for years 18:47:48 <frosch123> but yes, you need to commit them 18:48:06 <frosch123> anyway, what's broken with the citybuilder-gs lang file? 18:48:46 <planetmaker> english or cz? 18:48:53 <frosch123> english 18:49:53 <planetmaker> does it need to define langID for GS? 18:50:01 <planetmaker> i.e. it has no header 18:50:12 <frosch123> Error at line 15: Cannot change language properties after processing strings 18:50:29 <frosch123> oh, it's the ###### separator line :p 18:50:56 <planetmaker> he... ## might be special 18:51:12 <planetmaker> # is comment 18:51:17 <planetmaker> ## defines properties 18:51:21 <frosch123> yeah, without it it works 18:51:50 <Eddi|zuHause> planetmaker: you can easily "hg ci --mq" 18:52:19 <planetmaker> always? 18:53:13 <Eddi|zuHause> dunno. years ago when i attempted to try mq, there was "hg init --mq" 18:53:15 <Alberth> afaik GSes have helpfully no headers 18:54:08 <planetmaker> I guess the point is: if you use hg init --mq, then you got a mq repo, otherwise not. But hg init --mq is optional 18:54:28 <planetmaker> too long ago that I worked with mq it seems 18:54:55 *** Taede is now known as Guest1054 18:55:13 <Alberth> it's optional nowadays indeed 18:56:00 <Elyon> for sprite constants, would 'GROUNDSPRITE_RAIL_NE_SW' or 'GROUNDSPRITE_RAIL_NE' or something else entirely be preferred? 18:57:23 <frosch123> GROUNDSPRITE_ looks fine, there are already some constants with that prefix 18:57:50 <frosch123> for the directions, i would use the abbreviations from ottd 18:57:55 <Elyon> which are? 18:58:28 <Eddi|zuHause> grep Direction src/*.h 18:58:34 <frosch123> http://hg.openttd.org/openttd/trunk.hg/file/0015e242b4eb/src/track_type.h 18:58:56 *** Progman [~progman@p57A181F6.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 18:59:14 *** Progman [~progman@p57A1BB67.dip0.t-ipconnect.de] has joined #openttd 19:00:54 <frosch123> otoh, do you even need the direction? 19:01:09 <frosch123> isn't GROUNDSPRITE_RAIL enough? 19:01:26 <frosch123> iirc the layouts add the orientation themself 19:01:32 <Elyon> nah, what if the developer wants to specify custom sprites, either from TTD or the grf 19:01:50 <planetmaker> makes sense for referencing the sprite numbers, yes 19:01:50 <Elyon> the layouts only add orientation to bounding boxes, not the groundsprite 19:03:20 <Eddi|zuHause> don't station layouts automatically add +1 to the sprite IDs depending on X/Y direction? 19:03:30 <Elyon> not advlayouts anyway 19:03:38 <Eddi|zuHause> (vague half-kowledge alert) 19:03:52 <Elyon> I have to put 0x3F4 and 0x3F3 explicitly for the two directions when NFOing it 19:04:56 <Elyon> if the dev wants a different TTD sprite, the automatic orientation of GROUNDSPRITE_RAIL would also try to orientate the supplied sprite. To handle that, I could either ask devs to offset the second layout's TTD spriteid by -1, or have a special check in place for groundsprite == 0x3F4 19:05:44 <frosch123> hmm, yes, looks like the orientation is not handled automatically 19:05:56 <frosch123> so GROUNDSPRITE_RAIL_X and GROUNDSPRITE_RAIL_Y :) 19:06:00 <Elyon> yeah :) 19:06:34 <Elyon> from not having toyed enough with ottd source ... X is SW<->NE, right? 19:07:10 <Alberth> yes 19:07:14 <Elyon> wonderful! 19:07:15 <frosch123> yes, though i would have said NE->SW (oriented) :p 19:07:31 <Elyon> it's bidirectional though 19:07:41 <Alberth> positive X is to the left :) 19:07:54 <Elyon> oh ... okay 19:08:10 <Elyon> that seems rather opposite conventions 19:08:18 <frosch123> for railtiles it does not matter, but the world coordinates go that way 19:08:53 <frosch123> X is SW, Y is SE, Z is up 19:09:23 <Elyon> W is time? 19:09:56 <Elyon> hmm, okay. will keep that in mind; directions are southward 19:10:51 <Alberth> it happens when you assign the northern-most tile as (0, 0) :) 19:11:40 *** jjavaholic [~jjavaholi@grahamg63.plus.com] has joined #openttd 19:26:11 <Eddi|zuHause> positive X is to the lower left 19:26:23 <Eddi|zuHause> positive Y is to the lower right 19:26:44 <Eddi|zuHause> openttd has a weird coordinate system that makes you break your wrist when trying the right-hand-rule 19:28:22 <frosch123> you just need to sit on the other side of the screen 19:29:00 <Eddi|zuHause> or we need map rotation :) 19:34:34 *** blathijs [matthijs@tika.stderr.nl] has quit [Ping timeout: 480 seconds] 19:38:35 *** blathijs [matthijs@tika.stderr.nl] has joined #openttd 19:38:46 *** smoke_fumus [~smoke_fum@188.35.176.90] has quit [Ping timeout: 480 seconds] 19:50:48 *** itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd 19:53:17 *** jjavaholic [~jjavaholi@grahamg63.plus.com] has quit [Remote host closed the connection] 19:55:38 *** Plaete [~moffi@dsdf-5d82cdf9.pool.mediaWays.net] has joined #openttd 20:27:08 *** Wolf01 [~wolf01@host44-14-dynamic.31-79-r.retail.telecomitalia.it] has joined #openttd 20:27:36 <Wolf01> hi hi 20:29:00 <Alberth> o/ 20:29:20 <Elyon> hai 20:30:59 *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd [] 20:32:39 *** smoke_fumus [~smoke_fum@188.35.176.90] has joined #openttd 20:39:03 *** jjavaholic [~jjavaholi@grahamg63.plus.com] has joined #openttd 20:40:05 <Elyon> mm, segfaults 20:44:40 <andythenorth> well done 20:44:50 <andythenorth> not an easy prize to achieve :) 20:45:22 <Elyon> riiight :p 20:45:33 <Elyon> so apparently hmm 20:45:52 <Elyon> apparently I /need/ to use a spriteset for an item? 20:45:55 <Elyon> eventually? 20:45:56 <Elyon> (nml) 20:51:32 *** sla_ro|master [slamaster@95.76.27.245] has quit [] 21:04:15 *** Taede [~T@taedewerkhoven.co.uk] has joined #openttd 21:09:35 *** JacobD88 [~Thunderbi@cpc20-stap11-2-0-cust392.12-2.cable.virginm.net] has joined #openttd 21:12:02 *** Plaete [~moffi@dsdf-5d82cdf9.pool.mediaWays.net] has quit [Quit: Nettalk6 - www.ntalk.de] 21:12:43 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 21:16:30 <Elyon> hmm, so, for station advspritelayouts, it doesn't really make sense to reference `spriteset(index)` in the end, as there's only ever one spriteset available 21:17:03 <Elyon> this has been discussed here: http://dev.openttdcoop.org/issues/2746 - but was there ever any consensus as to how to approach this issue? 21:17:54 <Elyon> should the nml syntax just be `sprite: index`, where index is an index into whatever spriteset is currently available? If so, what if you want to use a TTDsprite instead of a GRFsprite? 21:18:02 <Elyon> slash realsprite? 21:18:42 <frosch123> i guess comparing industries and stations the roles of sets and sprites inside sets are somewhat swapped 21:19:03 <frosch123> for industries within a set you use construction stages by default 21:19:18 <frosch123> while you swap graphics by switching the set 21:19:28 <frosch123> for stations it's the other way around 21:19:31 <Elyon> hmm, yeah, quite true 21:19:40 <frosch123> the set is used for ther amount, while within the set you pick the graphics 21:19:43 <Elyon> I'm just wondering what the nml syntax (the most important part) should be 21:20:16 <Elyon> I'd rather not require `0x8000042D + index` of the grf developer 21:20:43 <frosch123> well, techncially you can use 7 spritesets within one station layout 21:20:48 <Elyon> if anything, I could just translate `spriteset(index)` to `ConstantNumeric(index)` 21:20:52 <frosch123> but i guess it is also fine to restrict it to one 21:21:00 <Elyon> how can you use 7 spritesets? 21:21:13 <frosch123> in the adv. spritelayout you can specifiy a var10 value 21:21:51 <frosch123> for each var10 value you can pick a different action2, i.e. a different spriteset 21:22:07 <Elyon> ah, right. Well, do you have any thoughts on desired nml syntax? 21:22:24 <frosch123> valid values for var10 are 0 to 7, but 2 is used for foundations, so effectively you only have 7 values available 21:22:42 <frosch123> i am not really fluent in nml syntax :p 21:22:53 <frosch123> is there an industry example? 21:23:12 <Elyon> well 21:23:14 <frosch123> hmm, let's look on bundles 21:23:21 <Elyon> there's an airport example 21:23:34 <Elyon> http://newgrf-specs.tt-wiki.net/wiki/NML:Spritelayout <- I am currently overloading the spritelayout 21:23:41 <Elyon> to work with stations as well 21:23:51 <frosch123> http://bundles.openttdcoop.org/ogfx-landscape/push/LATEST/ogfx-landscape.nml 21:23:56 <Elyon> the syntax is almost exactly the same, except for the pesky sprite resolving 21:24:28 <Elyon> wat. indentation 1, that's new :p 21:24:31 <frosch123> so, i think just allow the same references to spritesets, but fail if more than 7 are used 21:24:59 <Elyon> hmm ... that'll take some magic to resolve, I think ... 21:25:06 <frosch123> that file is the output of a c-preprocessor 21:25:14 <frosch123> so you are lucky there are linebreaks :p 21:25:21 <Elyon> :p 21:25:33 <frosch123> i guess for a start it is also fine, if only 1 is allowed 21:25:56 <Elyon> it'd be nice to support all 7 (or 8 if you feel like conflicting with foundations) 21:25:59 *** Pereba [~UserNick@177.17.86.11] has quit [Read error: Connection reset by peer] 21:26:12 <frosch123> well, the syntax would support it 21:26:15 <Elyon> but yeah, for a start 1 could suffice. After all, NML has been around for 3+ years with /no/ support for stations :D 21:26:26 <frosch123> so, it's not like it blocks something 21:26:33 <Elyon> but the spriteset available depends on the v-- oh 21:26:59 <frosch123> also, 3 years ago, there was no station set that required more than 1 set :p 21:27:36 <frosch123> it 7 sets add-on is really new, only chips and the newest isr may use it 21:28:18 <frosch123> the 2 sets is somewhat older, but i am not aware of any grf using it, if any then possible the newstations from last year, but that's newer than 3 years as well then 21:28:28 <Elyon> I see 21:28:39 <Elyon> hmm, I have a question related to var10/act1,2,3 chain etc. then 21:29:17 <Elyon> so the act1,2,3 chain is resolved repeatedly until ... AH 21:29:32 <frosch123> they form a decision tree 21:29:40 <Elyon> nevermind, I thought for a moment there the var10 resolve flag was a property of the layout as a whole 21:29:47 <frosch123> they are no imperative program code, that is run 21:29:58 <frosch123> instead they are asked for a result for every question 21:30:06 <Elyon> yeah :) 21:30:44 <Elyon> so say I set a sprite to resolve with var10=1 21:31:20 <Elyon> will it then /not/ draw it using the current act1,2,3 chain, and instead start a new chain with var10=1 and draw the sprite using that chain? 21:31:43 <frosch123> the layout is resolved first 21:31:58 <frosch123> the layout defines which var10 values need to be resolved 21:32:07 <Elyon> right, hmm 21:32:30 <Elyon> so ... lemme quickly jot down some syntax 21:32:30 <frosch123> if the layout used var10: 0,3 and 7, then spritesets will be resolved for var10=0, 3 and 7 :) 21:32:52 <frosch123> ideally the grf programmer would not have to check var 10 21:33:01 <frosch123> but nml would generate the switch automatically 21:33:05 <Elyon> mhm 21:33:26 <frosch123> i.e. the grf programmer only puts the spritelayout referecing the spritesets 21:33:40 <Elyon> try, catch, /finally/: each sprite is drawn only once, correct? 21:33:48 <Elyon> frosch123: yeah, I like this syntax 21:33:57 <Elyon> it stays true to ind/airports 21:34:01 <frosch123> and nml generates all from that: the action0, the layout callback, and the various spriteset results depending on var10 21:35:16 <Elyon> so if I supply, say, 7 spritesets, nml should generate a `switch 0:set_0; 1:set_1; 3:set_2 ...` etc.? 21:35:31 <Elyon> and warn/fail if more than 7 sets were requested? 21:35:46 <frosch123> that would be awesome :) 21:36:04 <Elyon> I shall make it so. First, though, I'll take your advice and implement it for /one/ spriteset 21:36:47 *** Taede [~T@taedewerkhoven.co.uk] has quit [Quit: He who can look into the future, has a brighter future to look into] 21:36:56 <frosch123> wrt. the grf: you would use the switches as from the nml code, but when encountering the spriteset, insert a varact2 for checking the layout callback, and then inserting a varaction2 for checking var10 21:37:15 <Elyon> although the syntax will be a bit weird until support for multiple spritesets is introduced. Unless I just hack in a translation of `spriteset(0) => ConstantNumeric(0)` 21:37:18 *** Taede [~T@taedewerkhoven.co.uk] has joined #openttd 21:38:01 <frosch123> "sprite: wind_powerplant_set(0)" <- spritesets would be used like that 21:38:13 <frosch123> so, i guess, just use the first one that is encountered 21:38:41 <Elyon> so it goes act3 -> varact2(select_spriteset) -> act1(spriteset_selected) ? 21:38:49 *** Guest1054 [~Taede@cpc4-linl9-2-0-cust57.18-2.cable.virginm.net] has quit [Quit: leaving] 21:39:30 <Elyon> then, another question: what goes in the `graphics` section of the station item, if the spritesets are selected exclusively from the layout? 21:39:48 <frosch123> act3 -> all the switches from nml -> [ varact2(callback_id) -> varact(var10) -> act2 ] 21:40:05 <frosch123> where the [ ... ] part is generated from the nml spritelayout 21:40:23 <Elyon> yeah, sounds great 21:40:51 <frosch123> in the graphics section you put "foundation_graphics", and as default the start to the "all the switched from nml" 21:41:03 <frosch123> you still have to link the spritelayout to the item via switches 21:41:27 <Elyon> I've linked it as a property `layouts` currently 21:41:51 <frosch123> ideally there would be no property, but it would be auto-generated by nml 21:42:05 <Elyon> no graphics property you mean? 21:42:09 <frosch123> just like the callback-flags propery is generated depending on the stuff in the graphics section 21:42:44 <Elyon> in nfo I usually just use a dummy act2 as the final act2 iirc, as the advspritelayout does the heavy lifting anyway 21:43:33 <Elyon> and how would you link the spritelayout via switches? You can't switch between advspritelayouts, only re-resolve with var10 though? 21:46:17 <Elyon> huh, paste.openttdcoop.org doesn't have nml syntax :p 21:48:20 <frosch123> https://paste.openttdcoop.org/phaylykhz <- i mean something like that 21:48:30 <frosch123> ^Spike^: why is there no longer a "forever" paste? 21:48:44 <Elyon> I was wondering the same thing 21:49:18 <frosch123> Elyon: how do you mean "you cannot switch between advspritelayouts" ? 21:49:32 <Elyon> and ah, I was authoring a slightly more elaborate example, possibly for inclusion in the ancient issue related to nml stations 21:49:49 <frosch123> callback 14 selects the spritelayout 21:49:51 <Elyon> frosch123: you can't varaction2 -> station_advspritelayout 21:49:53 <Elyon> wait 21:49:57 <Elyon> hmm 21:50:03 <Elyon> I haven't looked at callback 14 21:50:21 <frosch123> essentially you can do varaction2 -> spritelayout 21:50:35 <Elyon> that's exactly what I said the opposite of 21:50:49 <frosch123> that's what i mean with "varaction2(callbackid)" followed by "varaction2(var10)" 21:50:51 <Elyon> and this works for advspritelayout as well? 21:50:54 <frosch123> it's supposed to emulate taht 21:51:40 <frosch123> callback14 selects a spritelayout to use, but unlike as for industries/objects/... it does not link to it, but return an index into action0 21:52:03 <frosch123> the indexed layout then specifies the var10 to use to resolve the spritesets 21:52:04 <^Spike^> ehm frosch123 let me fix that then 21:52:06 <^Spike^> i blame update :D 21:52:39 <frosch123> :) 21:52:40 <^Spike^> they added an option that explains it 21:52:43 <^Spike^> should be fixed now 21:52:56 <frosch123> yup :) 21:52:57 <^Spike^> btw also added squirrel highlighting thnx to Sylf on paste so 21:53:33 <frosch123> oh, maybe sylf can also do a nml highlighter then :p 21:53:42 <^Spike^> i shall say nothing about what i see 21:53:47 <^Spike^> (love being admin sometimes :)) 21:54:10 <Elyon> ruby does an okay job of matching the nml syntax actually 21:54:30 <Elyon> at least, it's what I'm using to highlight nml 21:54:42 <frosch123> the nml repository has some syntax highlighting files and a generator for reserved words 21:54:46 <frosch123> maybe that can be reused 21:54:57 <Elyon> probably. there's no vim highlighting though 21:55:10 <^Spike^> don't talk about vim highlighting 21:55:18 * Elyon talks about vim highlighting 21:55:30 <^Spike^> because i got fed up with having to do my powershell stuff for vmware using rdp i install a powershell vim highlighter :D 21:55:53 <Elyon> :D 21:56:05 <^Spike^> they do exist for some reason :) 21:56:14 <^Spike^> and it's good enough to write my simple powershell stuff.... 21:56:21 <^Spike^> love having automatic migrations :D 22:02:50 <frosch123> Elyon: i guess the difference to industry/object layouts would be that that the spritelayout would reference spritegroups instead of spritesets 22:03:10 <Elyon> hmm ... 22:03:12 <Elyon> okay? 22:03:40 <Elyon> (so var2(callback) -> var2advspritelayout overriding the stationprop advspritelayout?) 22:05:07 <frosch123> https://paste.openttdcoop.org/pzjtzla8o <- so, more like that 22:05:17 <frosch123> but, i guess for a first version that can be skipped as well 22:05:56 <Elyon> hmm, I think I understand. I haven't used callback 14 before 22:06:13 <frosch123> since the little/lots thingie does not appear quite popular in the current meta-game, it may make sense to allow direct spriteset references anyway 22:08:43 <Elyon> direct spriteset references from where? 22:09:14 <frosch123> if nml puts those var0C and var10 varaction2 at the end, it would also magically allow the grf developer to use temporary storages 22:09:36 <frosch123> since they would be shared between callback14 and the various var10 sprite resolves 22:09:51 <Elyon> hmm, that seems ideal 22:10:00 <frosch123> Elyon: spriteset references from the spritelayout, without intermediate spritegroup 22:10:18 <frosch123> like in the earlier example 22:10:20 <Elyon> implementing rudimentary station support seems easy enough. Supporting every NFO-supported use-case, however, does not 22:10:38 <Elyon> ah, yes 22:11:02 <frosch123> it does not look that rudimentary to me :p 22:11:24 <frosch123> it rather looks like pretty much all to me :) 22:11:47 <Elyon> huh? 22:11:49 <Elyon> all what? 22:12:19 <frosch123> what "nfo-supported use-case" are you missing? :p 22:13:12 <Elyon> multiple spritelayouts, for one 22:13:25 <Elyon> and multiple spritesets in a layout, as another thing 22:14:01 <frosch123> ah, i was only considering the syntax 22:14:08 <Elyon> hence, rudimentary: it's possible to build a regular stationset with what I have already, but if you want any sort of fancypants conditionals and callbacks, it's still not ready 22:14:11 <Elyon> aah 22:14:18 <frosch123> i think the syntax covers all cases, it can be implemented in steps of course 22:14:23 <Elyon> of course 22:14:44 <Elyon> I have a more complete example coming up, perhaps you can tell me if I've understood your suggestions properly 22:15:48 <Elyon> ah, there's of course the issue that a station expects two spritelayouts 22:16:00 <Elyon> one for each orientation 22:16:43 <frosch123> hmm, so we need a layoutgroup? 22:16:48 <Elyon> I don't know, maybe so 22:17:14 <frosch123> layoutgroup layout1 { X: stationlayout1; Y: stationlayout2 } 22:17:19 <Elyon> the thing is, you can't `switch` to just one spritelayout. It needs two or it segfaults 22:17:21 <frosch123> but yeah, that makes it indeed more difficult 22:18:05 <Elyon> well, I like the syntax for that, /but/ that introduces a new keyword 22:19:09 <frosch123> it also does not quite fit with the var10 thing i suggested 22:19:37 <Elyon> a `layoutgroup` (with exactly two layouts, could be called a layoutpair instead) then translates to either a stationprop-advspritelayout or an action2-advspritelayout, depending on the result of resolving sprites? 22:19:44 <Elyon> well, why not? 22:19:56 <Elyon> it'd still just be an action2-advspritelayout in the end 22:20:40 <frosch123> the two spitelayouts could (and possibly very likely would) use different spritesets 22:20:49 <frosch123> so the var10 chain also need to check orientation 22:20:51 <Elyon> ah 22:20:58 <frosch123> to know which spritelayout is actually used 22:21:08 <frosch123> unless you separate the var10 values 22:21:11 <Elyon> is that an issue? 22:22:57 <frosch123> well, is there actually a variable to check orientation? :p 22:23:06 <Elyon> I believe there is 22:23:13 <Elyon> I seem to recall doing it, lemme check 22:25:15 <frosch123> hmm, var40 bit 24 i guess 22:25:59 <Elyon> how so? 22:26:25 *** gelignite [~gelignite@i528C339B.versanet.de] has quit [Quit: http://bit.ly/nkczDT] 22:26:47 <Elyon> everything seems to flip based on orientation, I can't figure out how to actually /figure out/ orientation 22:27:24 <frosch123> var40 contains the "tile", which i believe is also alternating 22:27:37 <Elyon> yeah 22:27:50 <Elyon> `stationlayout`, `layoutgroup` `layoutpair` ... hmm. 22:28:01 <Elyon> is there anything else that depends on a specific number of layouts? 22:28:07 <frosch123> but, this is all quite weird, i am not sure anymore the current syntax is ideal :) 22:28:38 <Elyon> possibly not. Hence; pre-implementation discussion :) 22:29:10 *** TomyLobo [~foo@ip5b417367.dynamic.kabel-deutschland.de] has joined #openttd 22:29:14 *** TomyLobo [~foo@ip5b417367.dynamic.kabel-deutschland.de] has quit [] 22:32:13 <Elyon> what was this splitting you mentioned? 22:32:44 <Elyon> I don't think we need to worry so much about unwieldy actions being generated. At least, my primary concern is the required nml syntax 22:33:46 <frosch123> splitting? 22:34:39 <Elyon> separating the var10 values 22:35:22 <frosch123> https://paste.openttdcoop.org/pzjtzla8o?/pzjtzla8o <- at the end there is a "varaction2(var10)" 22:35:32 <frosch123> which selects the spritegroup/spriteset 22:35:43 <Elyon> hmm, yes 22:35:54 <Elyon> but that depends on whether it's layout_x or layout_y 22:36:02 <frosch123> for every used spriteset you need a different var10, though possibly you can also use the orientation 22:36:03 <Elyon> as you said 22:36:49 <frosch123> so, unless you completely separate the orientations with different var10 (0,1 for X, 4,5 for Y), you need to check orientations 22:37:06 <Elyon> ah 22:37:15 <Elyon> and I cannot see any way to check orientation 22:37:29 <frosch123> nfo newgrfs would likely use the same spritegroups for both orientations, but different sprites inside them 22:37:40 <Elyon> mhm 22:37:41 <frosch123> so, maybe that would also be an option 22:38:01 <Elyon> hmm 22:38:15 <frosch123> maybe the orientation should just be a parameter to the spritelayout 22:38:27 <frosch123> spritegroup1(0) -> spritegroup1(2* 22:38:32 <frosch123> spritegroup1(0) -> spritegroup1(2*0 + orientation) 22:38:33 <frosch123> or something 22:38:55 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer] 22:38:59 <frosch123> that would make it easier for nml and more close to traditional station grfs 22:39:04 <Elyon> or inferred from the index into the layoutgroup 22:39:11 <Elyon> s/into/in 22:39:41 <frosch123> if the spritelayout would have a built-in orientation parameter, nml could create two layouts from it 22:39:52 <frosch123> with the orientation offsets already evalauated 22:40:07 <frosch123> hmm, yeah, i guess i like that more than the "layoutgroup" 22:40:14 <Elyon> okay 22:40:55 <Elyon> so `spritelayout(station_layout_x, STATION_ORIENTATION_X) { ... }`? 22:41:38 <Elyon> or ... I'm not sure I follow just yet 22:42:42 <Elyon> so adding an optional parameter to the `spritelayout` instead of adding an entirely new block? 22:43:01 <Elyon> (optional and useless for spritelayouts for other things than stations, but mandatory for stations) 22:44:05 <frosch123> i somehow want to enforce that sprites for different orientations must follow each other in the spriteset 22:45:00 <Elyon> hmm... why? 22:45:14 <Elyon> that seems an odd uh ... index squatting 22:45:30 <Elyon> it would make the syntax neater, but ... 22:45:45 <Elyon> s/syntax/implementation 22:46:14 <Elyon> and what about sprites that are used identically in both orientations? 22:47:06 <Elyon> enforcing realsprite duplication seems a bit weird to me - but I can see why you'd prefer that solution 22:47:07 <frosch123> yeah, those two cases :) either same sprite, or sprites follow each other. but not entirely different spritesets for direction 22:47:33 <Elyon> enforcing same sprite would be too limiting 22:47:43 <Elyon> I think? 22:47:51 <Elyon> yeah... 22:48:38 <frosch123> i just want to prevent that using different spritesets for orientations looks like the normal solution in nml, snice that's the opposite of what the grf expects 22:48:51 <Elyon> hah, understandable 22:49:26 <Elyon> well, if you use a +1 offset for Y-orientation sprites consistently, you'd even be able to skip the STATION_ORIENTATION_ parameter to spritelayouts 22:49:33 <Elyon> still need a group though 22:49:39 <Elyon> a layoutgroup I mean? 22:50:00 <Elyon> or some way of coupling two spritelayouts together 22:50:51 <Elyon> ooooh 22:50:56 <Elyon> no, I see what you're getting at 22:51:15 <Elyon> you'd only need one spritelayout which NML would duplicate with +1 offsets for Y-orientation 22:51:16 <frosch123> https://paste.openttdcoop.org/pfzxi8oiw <- not exactly nice looking, but may do the job 22:51:28 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has left #openttd [] 22:52:14 <frosch123> hmm, maybe instead of "WITH_ORIENTATION" there could be a constant offset for Y orientation 22:52:23 <Elyon> +1 comes to mind 22:52:36 <Elyon> and, why do you need the spritegroups? 22:52:43 <frosch123> i.e. a compile-time offset that can be set to 0 for same sprite, 1 in the normal case, but also some other value if the grf author needs it 22:52:56 <frosch123> spritegroup is for the little/lots thingie 22:53:05 <frosch123> but, well, optional :) 22:53:09 <Elyon> okay. you can reference spritesets directly as well, right? 22:53:32 <Elyon> how would this compile-time offset be specified? 22:53:57 <Elyon> and how would the grfauthor specify it - per-sprite or per-grf? 22:55:09 *** JacobD88 [~Thunderbi@cpc20-stap11-2-0-cust392.12-2.cable.virginm.net] has quit [Quit: JacobD88] 22:55:45 <Elyon> minor suggestion: https://paste.openttdcoop.org/p4vxlnqap 22:56:05 <Elyon> spritelayout sprite parameter `orientation_offset`, defaults to 1 22:56:34 <Elyon> instead of the WITH_ORIENTATION/WITHOUT_ORIENTATION stuff 22:57:24 <frosch123> https://paste.openttdcoop.org/phpmgml8t <- next iteration 22:57:38 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has quit [] 22:57:46 <frosch123> ah, "orientation_offset" looks better indeed :) 22:58:45 <frosch123> hmm, so about the little/lots thingie, that needs a cargo type 22:58:52 <frosch123> let's see how vehicles do that in nml 22:58:55 <Elyon> I don't think it is strictly impossible to have the offset be runtime-constant instead 22:59:09 <Elyon> or even variable; you made a flag for that :p 22:59:51 <Elyon> but that is pretty advanced stuff considering everyone and their mum will manage with offsets `0` and `1` probably 23:00:15 *** pxr [~Mychomize@46-236-110-230.customer.t3.se] has quit [Quit: Leaving] 23:00:26 <frosch123> yup, so good enough for now 23:01:15 <frosch123> ah, so vehicles use the cargo label in the graphics section 23:01:18 <Elyon> so when NML spots a feature-4 spritelayout, it duplicates it and resolves the constant offsets? 23:01:23 <frosch123> so, i guess we can expose the same for stations 23:01:44 <Elyon> do you have an example for vehicle littlelots handy? 23:01:50 <Elyon> yeah, consistency is key :) 23:02:18 <frosch123> http://www.tt-wiki.net/wiki/NMLTutorial/Road_vehicle_cargo_graphics#The_complete_code <- for vehicles it's "loading" and "loaded" 23:03:20 <Elyon> ah, hmm! 23:03:25 <frosch123> [00:01] <Elyon> so when NML spots a feature-4 spritelayout, it duplicates it and resolves the constant offsets? <- essenatially it adds two layouts to the action0 and generates the two varaction2 for var0C and var10 in the switch-chain 23:03:40 <Elyon> yeah, that figures :) 23:05:21 <Elyon> so the first possible advspritelayout-resolving for a station is set as its prop 1A - all other spritelayouts are switched-into? 23:05:29 <Elyon> as varaction2s 23:05:59 *** Suicyder [~Suicyder@86.92.59.88] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Organize your IRC] 23:07:07 <Elyon> https://paste.openttdcoop.org/p5xzhdovj <- updated example from before 23:07:19 <Elyon> without loading/loaded distinction 23:09:43 <Elyon> (as you can see, ruby does an okay job of syntaxhighlighting - at least if you write comments as `//#` 23:09:46 <Elyon> ) 23:12:31 <frosch123> property 1A is a list of layouts 23:12:50 <frosch123> callback 14 returns a index into that list (+1 for orientation) 23:12:59 <Elyon> oh, ah 23:13:12 <Elyon> so all station advspritelayouts are defined in prop1A? 23:13:17 <frosch123> the propery is actually per station 23:13:21 <Elyon> yeah 23:13:29 <frosch123> so, the spriteset needs to figure out, in which item it is used 23:13:51 <frosch123> or rather the item needs to figure out, which spritelayouts it can reach, and add those 23:14:00 <frosch123> so, not quite straight forward 23:14:10 <Eddi|zuHause> something tells me the station spec is even more terrible than the rest of nfo... 23:14:17 <Elyon> well, true. I haven't looked into NMLs resolving of relateds 23:14:21 <Elyon> haha 23:14:27 <Elyon> it is featureful, at least 23:14:46 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has quit [Remote host closed the connection] 23:15:14 <Eddi|zuHause> half of the problem seems to be that it has a totally different handwriting than the industry/object/airport spec 23:15:27 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd 23:15:29 <Eddi|zuHause> while trying to achieve most of the same things 23:15:50 <Elyon> most things from ind/obj/air can still be leveraged with a bit of tweaking, though 23:15:55 <frosch123> Eddi|zuHause: i think we solved that issue 23:16:10 <frosch123> by figureing out how to emulate the industry behaviour for stations 23:16:17 <Elyon> in the end, the syntax should feel consistent with the rest of NML and I think that's feasible :) 23:17:09 <Elyon> hmm, to remove all my queued patches and rollback to remote tip, I just `hg qpop` all the patches, yes? 23:17:18 * Elyon loves starting from scratch after gaining further insights 23:17:29 <frosch123> qpop -a 23:17:34 <Elyon> ah, wonderful 23:18:08 <frosch123> "update -r qbase" may also work 23:18:23 <Eddi|zuHause> it doesn't actuall forget all the patches so far, it just rolls back the working copy 23:18:27 <Eddi|zuHause> +y 23:18:43 <frosch123> s/qbase/qparent/ 23:19:12 <Elyon> yeah, I manually removed the patches I didn't want and kept the few that aren't related to advspritelayouts 23:19:32 <frosch123> there are (automatic) tags qparent:qbase:...:qtip 23:19:34 <Eddi|zuHause> this is useful if you want to pull an update 23:19:48 <frosch123> handy for log -rqparent:qtip and stuff 23:19:51 <Eddi|zuHause> qpop -a; pull; update; qpush -a 23:20:04 <Elyon> neat 23:20:12 <frosch123> that's the lame way to do it though :p 23:20:28 <frosch123> "hg pull --rebase" does a more powerful 3-way merge 23:20:37 <Elyon> here we go 23:20:43 <frosch123> though you need to know how to rebase and resolve conflicts interactively 23:20:43 <Elyon> I'll get used to this eventually 23:21:05 <Elyon> I just vimdiff 23:23:08 <Wolf01> 'night all 23:23:14 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.] 23:23:15 <Elyon> goodnight! 23:23:18 <Elyon> ah 23:25:08 <Elyon> oh, minor issue; GROUNDSPRITE_RAIL_X is 1012, while GROUNDSPRITE_RAIL_Y is 1011 23:26:06 <Elyon> we could hardcode that check for 1012, but hardcoding magic numbers is neh 23:27:22 <Elyon> anyway, if it isn't hardcoded, the grfauthor either needs to set `orientation_offset: -1` for every single defaultgroundspriterail, or `ground` should default to -1, or all sprites should default to -1 23:28:22 <frosch123> hmm, or we swap X and Y 23:28:24 <Elyon> also, another decision to make: NML syntax for naming station classes? 23:28:29 <Elyon> that could also work 23:28:49 <frosch123> so the "offset" is applied as "+ 1 - offset" 23:28:53 <Elyon> mhm 23:29:09 <frosch123> bah, how stupid, why is Y < X :/ 23:29:15 <Elyon> so spritelayouts for stations are defined by their Y-orientation, and the X-orientation is generated from that? 23:29:20 <Elyon> I don't know :( 23:29:25 <frosch123> Elyon: objects also have classes 23:29:40 <Elyon> frosch123: oh, I'll just copy whatever they do then 23:29:47 <Elyon> if those classes have names, anyway 23:29:53 <frosch123> not sure whether they do it the same though :p 23:30:09 <frosch123> but they have a 4-byte identifier, and a name in the gui 23:30:16 <Elyon> nevermind how they do it; if it's already implemented one way for objects, we may as well provide the same syntax for stations 23:30:26 <Elyon> yeah, that is exactly the same for stations 23:31:27 <Elyon> also, subtracting offset will confuse many a grf-author 23:31:44 <Elyon> if they put the offset as '24' and it actually takes their spriteindex and subtracts 23 23:32:14 <frosch123> so, "GROUND_SPRITE_RAIL_X" and "orientation_offset: -1" ? good enough for the first version i guess :) 23:33:51 <Elyon> "GROUND_SPRITE_RAIL" suffices, I'd think 23:34:00 <Elyon> but yeah! 23:34:11 <Eddi|zuHause> you should probably completely abstract away this offset nonsense 23:34:24 <Elyon> how? 23:34:33 <Eddi|zuHause> i don't know... 23:34:33 <Elyon> for groundsprite, sure - but for the other sprites? 23:34:53 <Elyon> there are three very distinct cases really 23:35:05 <Eddi|zuHause> let the programmer provide both orientations as one spriteset, or so... 23:35:23 <Elyon> but that gets unwieldy and weird, actually 23:35:30 <Elyon> 0: same sprite for both orientations 23:35:42 <Elyon> 1: consecutive sprites for X and Y 23:35:50 <Elyon> 2: arbitrary offset between X and Y 23:36:01 <Elyon> `1` being default 23:36:14 <Elyon> it's as abstract as it gets, I think 23:36:26 <frosch123> i would make "0" the default 23:36:31 <Elyon> same sprite? 23:36:37 <frosch123> that makes the "-1" less surprising 23:36:49 <Elyon> but ... huh 23:37:16 <Elyon> most grfs would use consecutive separate sprites for each direction I would think? 23:37:37 <frosch123> well, actually, we should take a look at cats, what will turn out handy :p 23:37:44 <Elyon> and we'll figure out a way to get rid of `ground { orientation_offset: -1; }` eventually :D 23:37:49 <Elyon> haha :D 23:38:04 <Elyon> well, all the platforms need orientation and all the cargo doesn't 23:38:11 <Elyon> so there's a good mix of both cases in there 23:38:51 <frosch123> hmm, how about a built-in function "rail_track_ground" 23:38:53 <Elyon> but in general, when authors define stations they need orientation-specific sprites, I'd think? 23:39:04 <Elyon> `rail_track_ground` for? 23:39:17 <frosch123> which can be used inside the spritelayout instead of the groundsprite 23:39:24 *** glx [~glx@000128ec.user.oftc.net] has quit [Read error: Connection reset by peer] 23:39:30 <frosch123> and provides the correct y offset, handles snow and stuff 23:39:38 <Elyon> hmm, interesting 23:39:54 <frosch123> but, well, nothing for the first version :p 23:40:17 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 23:40:20 *** mode/#openttd [+v glx] by ChanServ 23:40:27 <Elyon> so `rail_ground` replaces `ground { sprite: GROUNDSPRITE_RAIL; orientation_offset: -1; }` entirely? 23:40:43 <frosch123> i just suggest it, because ottd has quite specific expectations for the groundtile of station tiles with track 23:40:56 <Elyon> what expectations are these? 23:40:58 <frosch123> since ottd does the magic for railtypes 23:41:02 <Elyon> ah, yes 23:41:24 <frosch123> SplitGroundSpriteForOverlay expects either SPR_RAIL_TRACK_X, SPR_RAIL_TRACK_Y, SPR_RAIL_TRACK_X_SNOW or SPR_RAIL_TRACK_Y_SNOW 23:41:34 <frosch123> the latter two for snow or desert (*sigh*) 23:41:42 <Elyon> :p 23:42:29 <frosch123> it's actually funny, how the default stations never handled snow :) 23:42:55 <frosch123> that's why the newgrf have to deal with that :p 23:43:22 <Elyon> hmm, is it possible to just specify `ground` without any block? If so, `ground` could expand to a climate-aware, snow/desert-aware rail-if-train-can-enter-tile-otherwise-ground-sprite 23:43:29 <Elyon> like a catch-all groundsprite 23:44:22 <Elyon> so, at least for stations and possibly for most/all other things, you'd just put `ground` 23:44:31 <frosch123> well, the orientation_offset is already special for stations, so i guess there can be another "groundsprite_track" item or something 23:44:33 <Elyon> or even leave it out and NML would supply a groundsprite always 23:44:45 <Elyon> hmm 23:44:54 <Elyon> groundsprite_station 23:45:04 <frosch123> well, non-track station tiles would not use that 23:45:12 <Elyon> why not? 23:45:20 *** Hazzard is now known as BiG_FISHBOT 23:45:31 <frosch123> non-track station tiles can use whatever ground they like, they do not display anything from the railtype grf 23:45:35 *** BiG_FISHBOT is now known as Hazzard 23:46:01 <frosch123> they would rather use one of GROUNDSPRITE_CONCRETE or GROUNDSPRITE_CLEARED etc 23:46:07 <frosch123> or a custom one 23:46:24 <Elyon> ah 23:46:28 <Elyon> yes, that is true 23:46:33 <Elyon> what is GROUNDSPRITE_CLEARED? 23:46:38 <Eddi|zuHause> hm. there was something about the track becoming visible on transparent non-track tiles 23:46:43 <frosch123> the dirt instead of grass 23:46:54 <Elyon> oh right 23:47:01 <frosch123> Eddi|zuHause: bug in the grf :) 23:47:33 <Eddi|zuHause> i think newstations did that, but that may just have been old... 23:47:47 <Elyon> well, wouldn't most stations (and spritelayouts in general) use `track` for train-accessible tiles and `GROUNDSPRITE_NORMAL` otherwise? 23:48:04 <frosch123> Eddi|zuHause: most likely transparency at that time only affected houses 23:48:10 <Elyon> blah, you're right 23:48:15 <Elyon> no reason to do /all/ the work with NML 23:48:25 <Elyon> meaningful defaults should suffice 23:48:46 <Elyon> I like the idea of groundsprite_rail 23:48:53 <Elyon> or track or something 23:48:58 *** Hazzard is now known as status 23:49:07 *** status is now known as Hazzard 23:49:18 <Elyon> and ground { sprite: <num>; } otherwise :) 23:50:11 *** Hazzard is now known as Hazzard_ 23:50:13 *** Hazzard_ is now known as Hazzard 23:50:19 *** Hazzard is now known as Hazzardkajkd 23:50:22 *** Hazzardkajkd is now known as Hazzard 23:50:29 <Elyon> hi Hazzard, are you bored? :p 23:52:23 <Hazzard> Eh, I'm having some irc troubles 23:52:48 <Elyon> :( 23:55:23 <Elyon> frosch123: https://paste.openttdcoop.org/pmo6qu1qr <- does this syntax look ready to implement support for? 23:56:14 <Elyon> oh, you wanted `orientation_offset` to default to `0`, so I need to specify it as `1` for the two platform `building`s 23:56:43 <frosch123> ow, what to do with "yoffset" and "yextent" wrt. orientation? 23:56:56 <frosch123> just swap them automatically? 23:57:13 <Elyon> it already does that 23:57:23 <Elyon> yoffset is actually xoffset in Y-orientation 23:57:39 <Elyon> super easy 23:57:53 <frosch123> what do you mean with "already"? your implementation? 23:58:44 <Elyon> no, grf 23:58:48 <Elyon> well, ottd 23:59:02 <frosch123> i don't think so, what's the point of the layout pairs then? 23:59:18 <Elyon> it interprets yoffset as if it was xoffset for the other orientation 23:59:37 <Elyon> I've childsprited enough cargo to know :p 23:59:41 <Elyon> or at least think I know 23:59:44 *** Progman [~progman@p57A1BB67.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 23:59:45 *** Hazzard is now known as BiG_FISHBOT 23:59:56 <frosch123> weren't you using the default layouts for now?