Config
Log for #openttd on 7th January 2015:
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?

Powered by YARRSTE version: svn-trunk