IRC logs for #openttd on OFTC at 2015-01-07
⏴ go to previous day
00:31:13 *** smoke_fumus|2 has joined #openttd
00:35:30 *** smoke_fumus has joined #openttd
01:19:23 <mgrunin> how autistic do you need to be
01:20:53 <Elyon> wow, two insults in as many lines
02:01:36 *** luaduck_zzz is now known as luaduck
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:32 <Elyon> nevermind all of that, I should have read the Action0Property comments
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:20 * Elyon is monologuing until someone wakes up
03:53:44 *** Flygon__ has joined #openttd
03:56:23 *** Biolunar has joined #openttd
04:27:26 *** Hirundo has joined #openttd
04:27:26 *** ^Spike^ has joined #openttd
04:27:56 *** XeryusTC has joined #openttd
04:28:56 *** planetmaker has joined #openttd
04:28:56 *** ChanServ sets mode: +o planetmaker
04:29:26 *** Hazzard has joined #openttd
04:30:26 *** Terkhen has joined #openttd
04:30:26 *** ChanServ sets mode: +o Terkhen
04:30:26 *** V453000 has joined #openttd
04:30:57 *** fonsinchen has joined #openttd
05:32:58 *** supermop has joined #openttd
05:56:16 *** Eddi|zuHause has joined #openttd
06:59:29 *** fkinglag has joined #openttd
07:35:08 *** HerzogDeXtEr has joined #openttd
08:00:42 <V453000> where can I find a list of all the land tiles?
08:01:00 <V453000> like which IDs is snow 1-asdf, which IDs is rough tiles, ...
08:02:37 <V453000> yeah mz is probably down
08:05:15 <V453000> guess opengfx+ landscape is best thing I could get atm
08:31:58 *** Memphis[zZz] has joined #openttd
09:11:06 *** Nothing4You has joined #openttd
09:14:40 *** ChanServ sets mode: +v tokai
09:19:26 *** Memphis[zZz] is now known as BlueSteel
09:23:37 *** gelignite has joined #openttd
10:09:06 *** Sheogorath has joined #openttd
10:16:10 *** itsatacoshop247 has quit IRC
11:50:51 *** Quatroking has joined #openttd
12:07:04 *** sla_ro|master has joined #openttd
12:12:16 *** gelignite has joined #openttd
12:26:27 *** Jinassi has joined #openttd
12:30:20 *** LadyHawk has joined #openttd
12:33:15 *** Supercheese is now known as Guest1019
12:33:20 *** Supercheese has joined #openttd
13:09:47 *** glevans2 has joined #openttd
13:23:05 *** LadyHawk has joined #openttd
13:35:21 *** Suicyder has joined #openttd
13:36:01 *** Jinassi has joined #openttd
13:44:38 *** engineerwolf has joined #openttd
14:00:34 *** Jinassi has joined #openttd
14:08:13 <Eddi|zuHause> (do i have to explain the joke?)
14:10:38 <peter1138> German / Brazil / 15
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:35 <__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 has joined #openttd
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:41 <b_jonas> tennis on a plastic field
14:35:06 <Eddi|zuHause> ice hockey: the puck is (roughly) a ball.
14:35:26 <Eddi|zuHause> archery: the target is (roughly) a ball, alternately, the arrow is (roughly) a ball
14:35:40 <Eddi|zuHause> boxing: the opponent's head is (roughly) a ball
14:35:56 <Eddi|zuHause> rowing: not entirely sure :p
14:36:30 <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:41:56 <Belugas> planets are balls. buwhahahah!!
14:42:33 <Belugas> (that is for the old head bangers around here ;) )
14:42:41 <b_jonas> trains are roughly balls
14:43:23 <Belugas> "My hands felt just like two BALLoons"
14:45:03 <planetmaker> if planets weren't balls, they wouldn't be planets by definition ;)
14:46:15 <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 has joined #openttd
14:50:16 <planetmaker> Eddi|zuHause, yes, that's why
14:50:32 <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:52:04 <planetmaker> yes. But that's true for balls, too, to a similar degree :)
14:52:04 <Eddi|zuHause> frosch123: there are tidal forces and stuff
14:53:05 <V453000> BALLS OF STEEL REGARDLESS
14:53:25 <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:04 <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:31 <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:13:18 *** TheMask96 has joined #openttd
15:54:40 *** quorzom has joined #openttd
16:03:29 *** glevans2 has joined #openttd
16:07:18 <dihedral> congratulations... you built a station?
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: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: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:12:03 <Eddi|zuHause> modern train stations set
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:49 <Eddi|zuHause> Elyon: was something weird like "ask me before you modify it"
16:12:58 <dihedral> CATS -> cought another train syndrome
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:35 <Eddi|zuHause> Elyon: needs better structure/handling
16:13:51 <Eddi|zuHause> and more flexibility
16:14:18 <Eddi|zuHause> i have made a plan somewhere, but it's probably in the german forum
16:14:21 <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: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: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:46 <dihedral> must i search the logs?
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: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: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:24 <dihedral> Eddi|zuHause: that is hillarious
16:20:26 <Belugas> or rather... i ruined my lofe ;)
16:20:28 <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: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: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: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: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:27:39 <Eddi|zuHause> that might have been a person taking part in this conversation :p
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:38 <Eddi|zuHause> no. you complain about real snow :p
16:29:22 <Eddi|zuHause> even though you live more southern than most of us :p
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:23 *** Jinassi 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:57 <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:45 <Eddi|zuHause> muxy and luukland were somehow closely involved with each other
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:37:19 *** TheMask96 has joined #openttd
16:39:53 <NGC3982> I'm trying to learn myself to use entry-exit
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:21 <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: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:18 <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:07 <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: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: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:56 <Elyon> from where I could supply pull requests?
17:03:13 <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: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: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:15 <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:17 *** oskari89 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:52 <frosch123> you can move changes between 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:49 <frosch123> usually we discuss it, and tear each others patches apart :p
17:14:01 <Elyon> that's what you do with pull requests anyway!
17:14:53 <frosch123> convert already committed stuff into mq patches
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: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:39 *** MTsPony 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:15 <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:45 <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:10 <frosch123> finally there are hg qimport and hg qfinish to commit and un-commit stuff
17:27:20 <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 has joined #openttd
17:39:15 *** ChanServ sets mode: +o Alberth
17:45:26 <DorpsGek> Commit by translators :: r27115 trunk/src/lang/irish.txt (2015-01-07 17:45:20 UTC)
17:45:27 <DorpsGek> -Update from WebTranslator v3.0:
17:45:28 <DorpsGek> irish - 10 changes by tem
17:55:04 *** FLHerne has joined #openttd
18:20:28 *** Jinassi has joined #openttd
18:26:21 *** Progman has joined #openttd
18:40:53 *** andythenorth has joined #openttd
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:32 <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:05 <frosch123> anyway, what's broken with the citybuilder-gs lang file?
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:28 <frosch123> oh, it's the ###### separator line :p
18:50:55 <planetmaker> he... ## might be special
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:53:13 <Eddi|zuHause> dunno. years ago when i attempted to try mq, there was "hg init --mq"
18:53:14 <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:22 <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:58:28 <Eddi|zuHause> grep Direction src/*.h
18:59:14 *** Progman 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: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:57 <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:34 <Elyon> from not having toyed enough with ottd source ... X is SW<->NE, right?
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: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:56 <Elyon> hmm, okay. will keep that in mind; directions are southward
19:10:50 <Alberth> it happens when you assign the northern-most tile as (0, 0) :)
19:11:40 *** jjavaholic 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:38:35 *** blathijs has joined #openttd
19:50:48 *** itsatacoshop247 has joined #openttd
20:32:39 *** smoke_fumus has joined #openttd
20:39:03 *** jjavaholic has joined #openttd
20:44:49 <andythenorth> not an easy prize to achieve :)
20:45:52 <Elyon> apparently I /need/ to use a spriteset for an item?
21:09:35 *** JacobD88 has joined #openttd
21:12:43 *** Myhorta 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: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: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: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:23 <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:52 <frosch123> is there an industry example?
21:23:14 <frosch123> hmm, let's look on bundles
21:23:21 <Elyon> there's an airport example
21:23:41 <Elyon> to work with stations as well
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: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: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:39 <Elyon> hmm, I have a question related to var10/act1,2,3 chain etc. then
21:29:18 <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: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:30 <frosch123> if the layout used var10: 0,3 and 7, then spritesets will be resolved for var10=0, 3 and 7 :)
21:32:30 <Elyon> so ... lemme quickly jot down some syntax
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: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:00 <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: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:38:01 <frosch123> "sprite: wind_powerplant_set(0)" <- spritesets would be used like that
21:38:12 <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: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:47 <frosch123> act3 -> all the switches from nml -> [ varact2(callback_id) -> varact(var10) -> act2 ]
21:40:04 <frosch123> where the [ ... ] part is generated from the nml spritelayout
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:30 <frosch123> ^Spike^: why is there no longer a "forever" paste?
21:48:44 <Elyon> I was wondering the same thing
21:49:17 <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: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:39 <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:02 <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:40 <^Spike^> they added an option that explains it
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:29 <^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: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:40 <Elyon> (so var2(callback) -> var2advspritelayout overriding the stationprop advspritelayout?)
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:10:00 <frosch123> Elyon: spriteset references from the spritelayout, without intermediate spritegroup
22:10:18 <frosch123> like in the earlier example
22:10:21 <Elyon> implementing rudimentary station support seems easy enough. Supporting every NFO-supported use-case, however, does not
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: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:18 <frosch123> i think the syntax covers all cases, it can be implemented in steps 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:42 <frosch123> hmm, so we need a layoutgroup?
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: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:58 <frosch123> to know which spritelayout is actually used
22:21:08 <frosch123> unless you separate the var10 values
22:22:56 <frosch123> well, is there actually a variable to check orientation? :p
22:23:13 <Elyon> I seem to recall doing it, lemme check
22:25:15 <frosch123> hmm, var40 bit 24 i guess
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: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:09 *** TomyLobo has joined #openttd
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:34:39 <Elyon> separating the var10 values
22:35:32 <frosch123> which selects the spritegroup/spriteset
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: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: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:41 <frosch123> so, maybe that would also be an option
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: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: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: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: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: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: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:50:00 <Elyon> or some way of coupling two spritelayouts together
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:28 *** andythenorth has left #openttd
22:52:14 <frosch123> hmm, maybe instead of "WITH_ORIENTATION" there could be a constant offset for Y orientation
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:55 <frosch123> spritegroup is for the little/lots thingie
22:53:04 <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:56:05 <Elyon> spritelayout sprite parameter `orientation_offset`, defaults to 1
22:56:35 <Elyon> instead of the WITH_ORIENTATION/WITHOUT_ORIENTATION stuff
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:51 <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: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:03:24 <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: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: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: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:13:12 <Elyon> so all station advspritelayouts are defined in prop1A?
23:13:17 <frosch123> the propery is actually per station
23:13:29 <frosch123> so, the spriteset needs to figure out, in which item it is used
23:13:50 <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:27 <Elyon> it is featureful, at least
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 has joined #openttd
23:15:28 <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: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: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: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: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: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:49 <frosch123> so the "offset" is applied as "+ 1 - offset"
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:25 <frosch123> Elyon: objects also have classes
23:29:40 <Elyon> frosch123: oh, I'll just copy whatever they do then
23:29:48 <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:10 <Eddi|zuHause> you should probably completely abstract away this offset nonsense
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:04 <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:14 <Elyon> it's as abstract as it gets, I think
23:36:26 <frosch123> i would make "0" the default
23:36:37 <frosch123> that makes the "-1" less surprising
23:37:17 <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: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:50 <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:29 <frosch123> and provides the correct y offset, handles snow and stuff
23:39:54 <frosch123> but, well, nothing for the first version :p
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:57 <frosch123> since ottd does the magic for railtypes
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: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:45:04 <frosch123> well, non-track station tiles would not use that
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: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: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:16 <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: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:21 *** 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: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:23 <Elyon> yoffset is actually xoffset in Y-orientation
23:57:53 <frosch123> what do you mean with "already"? your implementation?
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:45 *** Hazzard is now known as BiG_FISHBOT
23:59:56 <frosch123> weren't you using the default layouts for now?
continue to next day ⏵
