Back to Home / #openttd / 2015 / 01 / Prev Day | Next Day
#openttd IRC Logs for 2015-01-07

---Logopened Wed Jan 07 00:00:16 2015
00:32-!-supermop [] has joined #openttd
00:56-!-Eddi|zuHause [] has quit []
00:56-!-Eddi|zuHause [] has joined #openttd
01:16-!-fkinglag1 [] has quit [Ping timeout: 480 seconds]
01:34-!-smoke_fumus [~smoke_fum@] has quit [Read error: Connection reset by peer]
01:49-!-DDR [] has quit [Read error: Connection reset by peer]
01:50-!-DDR [] has joined #openttd
01:59-!-fkinglag [] has joined #openttd
02:26-!-_hsknz [~hsknz@] has quit [Quit: :)]
02:35-!-HerzogDeXtEr [~flex@] has joined #openttd
02:35-!-liq3 [] has quit []
02:47-!-DDR [] has quit [Read error: Connection reset by peer]
03:00<V453000>where can I find a list of all the land tiles?
03:01<V453000>like which IDs is snow 1-asdf, which IDs is rough tiles, ...
03:01<Elyon>supposedly but I can't connect
03:02<V453000>yeah mz is probably down
03:05<V453000>guess opengfx+ landscape is best thing I could get atm
03:24-!-Yotson [~Yotson@2001:980:6ac8:1:c109:6eb9:2e41:3b6] has joined #openttd
03:31-!-Memphis[zZz] [] has joined #openttd
04:04-!-supermop [] has quit [Ping timeout: 480 seconds]
04:11-!-Nothing4You [] has joined #openttd
04:12-!-tokai|mdlx [] has quit [Quit: c('~' )o]
04:14-!-tokai [] has joined #openttd
04:14-!-mode/#openttd [+v tokai] by ChanServ
04:19-!-Memphis[zZz] is now known as BlueSteel
04:23-!-gelignite [] has joined #openttd
04:46-!-MJP [] has joined #openttd
05:06-!-Sheogorath [] has quit [Remote host closed the connection]
05:09-!-Sheogorath [] has joined #openttd
05:16-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Ping timeout: 480 seconds]
05:38-!-gelignite [] has quit [Quit:]
06:09<V453000>H Y
06:30<Elyon>H I
06:50-!-Marshy [~oftc-webi@] has joined #openttd
06:50-!-Quatroking [] has joined #openttd
07:07-!-sla_ro|master [slamaster@] has joined #openttd
07:12-!-gelignite [] has joined #openttd
07:26-!-Jinassi [] has joined #openttd
07:29-!-LadyHawk [] has quit []
07:30-!-LadyHawk [] has joined #openttd
07:33-!-Supercheese is now known as Guest1019
07:33-!-Supercheese [] has joined #openttd
07:38-!-Guest1019 [] has quit [Ping timeout: 480 seconds]
07:51-!-tokai [] has quit [Ping timeout: 480 seconds]
07:52-!-Marshy [~oftc-webi@] has quit [Remote host closed the connection]
08:08-!-glevans2 [] has quit [Ping timeout: 480 seconds]
08:09-!-glevans2 [] has joined #openttd
08:11-!-Jinassi [] has quit [Quit: Nettalk6 -]
08:22-!-LadyHawk [] has quit []
08:23-!-LadyHawk [] has joined #openttd
08:35-!-Suicyder [~Suicyder@] has joined #openttd
08:36-!-Jinassi [] has joined #openttd
08:44-!-engineerwolf [] has joined #openttd
08:48-!-Jinassi [] has quit [Quit: Nettalk6 -]
08:52-!-engineerwolf [] has quit [Quit: Leaving]
09:00-!-Jinassi [] has joined #openttd
09:00-!-Jinassi [] has left #openttd []
09:04<Eddi|zuHause>i guess we can now add this to the long list of date formats :p
09:06<@peter1138> Err
09:08<Eddi|zuHause>(do i have to explain the joke?)
09:10<@peter1138>German / Brazil / 15
09:12<Eddi|zuHause>that is not really the joke :)
09:13<V453000>Germany sent 7 nuclear bombs to 1 brazil last year
09:13<__ln___>peter1138: i think it's related to the sport where adult men run across a grass field and try to kick a ball.
09:13<V453000>brazil was morally devastated because they could collect just one
09:14<V453000>it is, fuck football, huzzah
09:27<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
09:29-!-frosch123 [] has joined #openttd
09:31<frosch123>hello sir belugas :)
09:31<__ln___>Eddi|zuHause: counter examples: chess; brockian ultra-cricket
09:32<Eddi|zuHause>cricket doesn't involve walking and a ball?
09:32<__ln___>the usual cricket probably, but brockian ultra-cricket is a bit different.
09:33<@peter1138>ice hockey
09:33<b_jonas>tennis on a plastic field
09:34<@planetmaker>chess :P
09:35<Eddi|zuHause>ice hockey: the puck is (roughly) a ball.
09:35<Eddi|zuHause>archery: the target is (roughly) a ball, alternately, the arrow is (roughly) a ball
09:35<Eddi|zuHause>boxing: the opponent's head is (roughly) a ball
09:35<Eddi|zuHause>rowing: not entirely sure :p
09:36<SpComb>the boat is roughly a ball?
09:37<Eddi|zuHause>i suppose the finish line is roughly a ball :p
09:37<__ln___>rowing moves H2O atoms, which are roughly balls
09:37<@Belugas>yoho sir frosch123 :)
09:37<Eddi|zuHause>and chess has 32 roughly balls on a paper field
09:37<Eddi|zuHause>and moving your arm is (roughly) running/walking :p
09:38<@Belugas>computers. keys are roughly balls. fingertips are roughly balls. eyesball are... balls
09:39<@peter1138>balls are balls
09:40<@planetmaker>ho, sir belugas!
09:41<@Belugas>planets are balls. buwhahahah!!
09:42<@Belugas>hello planetmaker :)
09:42<V453000>BALLS OF STEEL
09:42<V453000>hello everybody
09:42<@Belugas>Balls To the Wall!
09:42<@Belugas>(that is for the old head bangers around here ;) )
09:42<b_jonas>trains are roughly balls
09:43<@Belugas>"My hands felt just like two BALLoons"
09:45<@planetmaker>if planets weren't balls, they wouldn't be planets by definition ;)
09:46<Eddi|zuHause>V453000: more like balls of iron and nickel, with a few bits of other stuff as coating
09:47<Eddi|zuHause>planetmaker: doesn't everything with sufficient mass automatically form into some ball shape?
09:49-!-smoke_fumus [~smoke_fum@] has joined #openttd
09:50<@planetmaker>Eddi|zuHause, yes, that's why
09:50<@planetmaker>if it's too small to form a ball-shape, it's by definition not a planet anymore
09:51<@planetmaker>(but possibly a dwarf planet, asteroid, comet, whatever...)
09:51<Eddi|zuHause>well, there are certainly ball shaped dwarf planets :)
09:51<frosch123>aren't they all elipsoids?
09:51<frosch123>due to rotation?
09:52<@planetmaker>yes. But that's true for balls, too, to a similar degree :)
09:52<Eddi|zuHause>frosch123: there are tidal forces and stuff
09:53<Eddi|zuHause>frosch123: the exact shape of the geoid is a very very lengthy and afaik still ongoing discussion
09:53<Eddi|zuHause>frosch123: that's why the GPS doesn't say 0° if you stand on the 0° line in greenwich
09:54<Eddi|zuHause>because the brits use a different geoid than the americans
09:54<@planetmaker>Eddi|zuHause, not really. But as with every changing thing, it's good to update stuff occasionally. Or measure more accurately
09:54<@planetmaker>it's just the equi-potential surface taken at sea level. "just" :P
09:55<@planetmaker>thus it's already difficult when measured on land... you have to account for the (partially) unknown ground below you
09:56<@peter1138>Oh, XMBC was renamed.
09:56<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
09:57<Eddi|zuHause>and unifying those is probably a weird political thing
09:57<@planetmaker>not really that much
09:58<@planetmaker>more political is what's on the surface
09:58<@planetmaker>but that's of no interest for the geoid
09:58<b_jonas>Eddi|zuHause: like, the political leaders play "you mama so fat it makes the geoid flatter near your country" with each other?
09:59<@planetmaker>it actually wouldn't make it flatter but more pointy-shaped ;)
10:00<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?"
10:08-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
10:13-!-TheMask96 [] has joined #openttd
10:37-!-liq3 [] has joined #openttd
10:54-!-quorzom [] has joined #openttd
11:01-!-glevans2 [] has quit [Ping timeout: 480 seconds]
11:03-!-glevans2 [] has joined #openttd
11:06<Elyon>frosch123: thanks to your suggestion of leveraging nml, I now have this:
11:07<dihedral>congratulations... you built a station?
11:07<Elyon>a custom station. In NML.
11:08<Elyon>rudimentary, of course, but small moves :)
11:08<dihedral>custom, because you used the same tile over and over again?
11:09<dihedral>yes, small steps at a time ;-)
11:09<Eddi|zuHause>... it's a dihedral. how did that happen?
11:09<dihedral>must have been a glitch in the matrix
11:09<Elyon>custom in that it's a station newgrf
11:10<Elyon>with a custom (yet identical) layout to the most basic platform, it's ... rargh
11:10<Elyon>the teaser is the code, not the station!
11:11<dihedral>the teaser is the link, not the picture :-P
11:11<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)
11:12<Eddi|zuHause>modern train stations set
11:12<Eddi|zuHause>by red*star
11:12<dihedral>sounds like a syndrome if you ask me
11:12<Elyon>and I'm working on CATS, which has taken me to working on leveraging nml. So, NML then CATS then who knows? :D
11:12<dihedral>modern train station syndrom
11:12<Elyon>what's with the license?
11:12<Eddi|zuHause>Elyon: was something weird like "ask me before you modify it"
11:12<Elyon>oh, one of those
11:12<dihedral>CATS -> cought another train syndrome
11:13<Elyon>Eddi|zuHause: but what about the graphics?
11:13<Elyon>that's just redistribution or?
11:13<Eddi|zuHause>Elyon: they're beautiful, but cumbersome to build
11:13<Eddi|zuHause>Elyon: needs better structure/handling
11:13<Elyon>mm :)
11:13<Eddi|zuHause>and more flexibility
11:14<Elyon>I see!
11:14<Eddi|zuHause>i have made a plan somewhere, but it's probably in the german forum
11:14<Elyon>and I presume some form of free software license is what you had in mind?
11:14<Eddi|zuHause>yes. either GPL or CC-BY-SA
11:15<Elyon>supposedly CC licenses aren't intended for code
11:15<Elyon>or software, as it were
11:15<Eddi|zuHause>yes, has some problems
11:15<Elyon>although I have released many a source with CC-BY in the past
11:15<Eddi|zuHause>but people around here are usually "nice" anyway
11:16<Elyon>mhm :D
11:16<Elyon>I've noticed
11:16<dihedral>"nice" ... used thoe quotationmarks by accident did we?
11:17<Eddi|zuHause>*cough* all things canadian *cough*
11:17<Elyon>NICE: intentionally cynical expectations
11:17<dihedral>so which one of the guys you've met adds reason for the quotation amrks then?
11:17<dihedral>Belugas, I am sure it was Belugas ... though they other odd guy was TrueBrain :-P
11:17<Eddi|zuHause>or people that rage-quit the community, like richk
11:18<dihedral>i prefer those who got kicked ... like yorick
11:18<Eddi|zuHause>dihedral: you probably missed the canadian bit, about half a year ago
11:18<@Belugas>yorick... yurk
11:18<@Belugas>baddd memories
11:18<dihedral>must i search the logs?
11:18<@Belugas>yo dihedral :)
11:18<dihedral>sorry Belugas
11:18<Elyon>logs schmogs
11:18<dihedral>hey ho sir
11:19<dihedral>how's the kid doing?
11:19<@Belugas>how is new year starting for you?
11:19<dihedral>must be something like 9 now?
11:19<@Belugas>11 ;)
11:19<dihedral>wow - i was away for a bit!
11:19<@Belugas>he's going well, about to get a fine young man
11:19<@Belugas>like his dad
11:19<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...
11:20<dihedral>you are 11? you look much older, you know :-D
11:20<@Belugas>yeah... life ruined me
11:20<dihedral>Eddi|zuHause: that is hillarious
11:20<@Belugas>or rather... i ruined my lofe ;)
11:20<Elyon>wha... what?
11:20<Eddi|zuHause>... and then he replaced all bananas versions of his GRFs with some with scrambled graphics
11:20<Eddi|zuHause>... and rage-quit
11:22<dihedral>Belugas: now what makes you say stuff like that?
11:22<dihedral>Eddi|zuHause: lovely! that's the way forward...
11:22<dihedral>was there not another guy in the forums who did that?
11:22<@Belugas>because... i was a bad boy ?
11:23<dihedral>what kind of misschif did you get youself into this time?
11:23<Eddi|zuHause>dihedral: there was someone who quit the forum, and replaced all his posts he ever made with "..."
11:23<Eddi|zuHause>dihedral: which was actually the same person :)
11:23<Elyon>by the way, regarding commits; it seems to me that looong commits that fully implement a feature/change is preferred?
11:24<Eddi|zuHause>Elyon: not really
11:24<dihedral>Eddi|zuHause: there was another guy
11:24<Sacro>mm, old skool peeps
11:24<Eddi|zuHause>dihedral: there are lots of guys. you need to be more specific
11:25<Elyon>Eddi: oh, hmm. Actually now that you mention it, NML commits are spread merely minutes apart. Noted, thanks!
11:25*dihedral checks the forums
11:25<Eddi|zuHause>Elyon: in the end, it's about your style, but generally it's recommended that commits be smaller, more atomic
11:25<Elyon>that's what I'm used to as well
11:25<dihedral>where's the winter theme!!
11:25<Eddi|zuHause>dihedral: in the forum settings
11:26<Eddi|zuHause>some person complained too much about the winter theme destroying his eyes, so a setting to turn it off was introduced :p
11:26<@peter1138>1 character at a time
11:27<Eddi|zuHause>that might have been a person taking part in this conversation :p
11:28<Elyon>bind 'hg add . && hg commit -m `date`' to :write
11:28<@Belugas>i hate snow but not to that extend
11:28<dihedral>that's the guy
11:28<Eddi|zuHause>no. you complain about real snow :p
11:29<Eddi|zuHause>even though you live more southern than most of us :p
11:29<@Belugas>shitty white stuff
11:29<@Belugas>no good doing
11:29<dihedral>we had snow this winter - and i still have a can full of instant snow
11:30<Eddi|zuHause>dihedral: i don't remember what that was about.
11:30<@Belugas>lol... you "had" !
11:30-!-Jinassi [~jinassi@] has joined #openttd
11:30<dihedral>muxy got banned after that, got furious for something, and started editing all his posts into '...'
11:30<Eddi|zuHause>oh, that was the "we hate rubidium, because he fixed the security holes we abused" community?
11:31<dihedral>and above all else, there is luukland
11:31<Eddi|zuHause>yeah. that i meant
11:31<@Belugas>mmmh.. not sure about that one Eddi|zuHause
11:31<Eddi|zuHause>muxy and luukland were somehow closely involved with each other
11:32<Eddi|zuHause>no, but the name i was trying to not say was "OzTrans"
11:32<dihedral>and yorick wrote their patches
11:32-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
11:37-!-TheMask96 [] has joined #openttd
11:39<NGC3982>I'm trying to learn myself to use entry-exit
11:40<NGC3982>I want the train waiting closest to the station, to simply continue on the outer most empty track if the station is full
11:40<Eddi|zuHause>why would you do that?
11:41<NGC3982>I want it to continue traveling instead of waiting, not blocking the drop-off trains.
11:41<Eddi|zuHause>basically, the "firstred exit penalty" must be larger than the penalty for a whole roundtrip
11:42<Eddi|zuHause>default value is 10000, i think
11:42<Eddi|zuHause>so 100 tiles
11:43<dihedral>crossings over roads add penalty IIRC
11:45-!-luaduck is now known as luaduck_zzz
11:45<@Belugas>i think i love tropical screenshots...
11:47<@peter1138>I prefer tropical photos.
11:48<Eddi|zuHause>i'd settle for subtropic vacations
11:49<@Belugas>me too, peter1138! But... i have to wait a bit for my next ones ;)
11:49<Eddi|zuHause>... preferably avoiding greek ferries and asian flights
11:49<@Belugas>welll.. a bit... less then 3 months now!
11:58<frosch123>Elyon: i see, you are not taking the short route :)
11:59<frosch123>Elyon: the prediminant method for additions here are "mercurial queues"
11:59<frosch123>they result in closesy consecutive commits
11:59<frosch123>mq somehow invents the commit time depending on the patch size or something
11:59<frosch123>but maybe it is just random
12:00<Elyon>okay hmm
12:00<Elyon>frosch123: the 'patching nml to support stations' route seemed shorter than the 'formatting all my data so nml will eat it' route :D
12:01<frosch123>i thought one could just write the hex bytes into some baseaction
12:01<frosch123>but well, if you can use even more nml, you can also use the lang files :)
12:02<Elyon>although not really that useful for stations as they're (as far as I can tell) untranslated
12:02<frosch123>also, if you need some repo on the devzone: we already have eddi-nml, so there can also be a elyon-nml :po
12:02<Elyon>frosch123: :D :D
12:02<Elyon>from where I could supply pull requests?
12:03<Elyon>eventually, anyway
12:03<Elyon>or at the very least reference commits in NML issue tracker
12:03<frosch123>everyone is here anyway
12:06<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?
12:07<Elyon>(except spritelayout as that deserves its own commit either way)
12:07<frosch123>whatever suits you, and is easy to read
12:08<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
12:09<frosch123>as said, we use mercurial queues, we change history all the time
12:09<Elyon>hmm, I'll have to read up on that
12:11<Elyon>ah, that's neat
12:11<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
12:11<Elyon>so it's basically mini revision history as a patchset?
12:12<frosch123>it's a "history draft" :p
12:12<Eddi|zuHause>yes, the patches are what you want your commits in the end to look like
12:12<Elyon>I usually just use branches for that
12:12-!-oskari89 [] has joined #openttd
12:12<frosch123>if you notice a bug, you fix it in the original commit instead of adding a fix-commit
12:12<Eddi|zuHause>but you can go back and forth through the patches while you work
12:12<Elyon>that's neat
12:12<frosch123>you can move changes between commits
12:12<frosch123>reorder commits
12:13<Elyon>so only after you're done implementing a full changeset (with revisions to the uh, revisions) fully you push?
12:13<frosch123>some people call it "searching for the perfect patch series"
12:13<Elyon>haha :D
12:13<Elyon>I approve
12:13*Elyon `hg rollback`s
12:13<frosch123>usually we discuss it, and tear each others patches apart :p
12:13<frosch123>Elyon: hg qimport
12:14<Elyon>that's what you do with pull requests anyway!
12:14-!-liq3 [] has quit [Ping timeout: 480 seconds]
12:14<Elyon>qimport => ?
12:14<frosch123>convert already committed stuff into mq patches
12:16-!-Buntunub [] has quit [Ping timeout: 480 seconds]
12:17<Elyon>oh that's neat. But I've started from scratch with the intent of actually supplying a hopefully possibly sensible patchset
12:18<frosch123>that's also fine :)
12:21<Elyon>mq is a perfectionist's wet dream/night terror
12:22<Elyon>so anyway, to recap: I just `hg qnew <short-name>` repeatedly to generate multiple patches, each to-be-perfected?
12:23<frosch123>yes, with -m you can also add a commit message
12:24-!-liq3 [] has joined #openttd
12:24<frosch123>with qpush and qpop you can move the working copy
12:24<frosch123>if not applied you can also edit the patch files directly in .hg/patches
12:24<frosch123>esp. to edit commit messages
12:24-!-MTsPony [] has joined #openttd
12:24<frosch123>or if you like to also split or merge patches
12:25<frosch123>i have heard of a more modern "hg evolve" extension, but i am not aware of anyone here using it
12:25<Elyon>I will definitely be learning this mq
12:25<Elyon>version control control system
12:26<frosch123>in theory the patches are in a repository themself: ".hg/patches" is a repository
12:26<frosch123>so you can in theory save and restore previous patch versions, but i had never had a use case for that :p
12:27<frosch123>finally there are hg qimport and hg qfinish to commit and un-commit stuff
12:27<frosch123>i think that's about all :p
12:27<Elyon>seems powerful and useful
12:37<Eddi|zuHause>i've never quite got around to it
12:37<Eddi|zuHause>it's something that makes your work more annoying for a while until you are fluent with it
12:39-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
12:39-!-mode/#openttd [+o Alberth] by ChanServ
12:43-!-Jinassi [] has quit [Ping timeout: 480 seconds]
12:45<@DorpsGek>Commit by translators :: r27115 trunk/src/lang/irish.txt (2015-01-07 17:45:20 UTC)
12:45<@DorpsGek>-Update from WebTranslator v3.0:
12:45<@DorpsGek>irish - 10 changes by tem
12:55-!-FLHerne [] has joined #openttd
13:03-!-glx [] has joined #openttd
13:03-!-mode/#openttd [+v glx] by ChanServ
13:20-!-Jinassi [] has joined #openttd
13:20-!-Jinassi [] has left #openttd []
13:26-!-Progman [] has joined #openttd
13:31-!-Pereba [~UserNick@] has joined #openttd
13:40-!-andythenorth [] has joined #openttd
13:47<@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
13:47<@planetmaker>and then actually make use of that and regularily check in the patches
13:47<frosch123>afaik that is the default for years
13:47<frosch123>but yes, you need to commit them
13:48<frosch123>anyway, what's broken with the citybuilder-gs lang file?
13:48<@planetmaker>english or cz?
13:49<@planetmaker>does it need to define langID for GS?
13:50<@planetmaker>i.e. it has no header
13:50<frosch123>Error at line 15: Cannot change language properties after processing strings
13:50<frosch123>oh, it's the ###### separator line :p
13:50<@planetmaker>he... ## might be special
13:51<@planetmaker># is comment
13:51<@planetmaker>## defines properties
13:51<frosch123>yeah, without it it works
13:51<Eddi|zuHause>planetmaker: you can easily "hg ci --mq"
13:53<Eddi|zuHause>dunno. years ago when i attempted to try mq, there was "hg init --mq"
13:53<@Alberth>afaik GSes have helpfully no headers
13:54<@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
13:54<@planetmaker>too long ago that I worked with mq it seems
13:54-!-Taede is now known as Guest1054
13:55<@Alberth>it's optional nowadays indeed
13:56<Elyon>for sprite constants, would 'GROUNDSPRITE_RAIL_NE_SW' or 'GROUNDSPRITE_RAIL_NE' or something else entirely be preferred?
13:57<frosch123>GROUNDSPRITE_ looks fine, there are already some constants with that prefix
13:57<frosch123>for the directions, i would use the abbreviations from ottd
13:57<Elyon>which are?
13:58<Eddi|zuHause>grep Direction src/*.h
13:58-!-Progman [] has quit [Ping timeout: 480 seconds]
13:59-!-Progman [] has joined #openttd
14:00<frosch123>otoh, do you even need the direction?
14:01<frosch123>isn't GROUNDSPRITE_RAIL enough?
14:01<frosch123>iirc the layouts add the orientation themself
14:01<Elyon>nah, what if the developer wants to specify custom sprites, either from TTD or the grf
14:01<@planetmaker>makes sense for referencing the sprite numbers, yes
14:01<Elyon>the layouts only add orientation to bounding boxes, not the groundsprite
14:03<Eddi|zuHause>don't station layouts automatically add +1 to the sprite IDs depending on X/Y direction?
14:03<Elyon>not advlayouts anyway
14:03<Eddi|zuHause>(vague half-kowledge alert)
14:03<Elyon>I have to put 0x3F4 and 0x3F3 explicitly for the two directions when NFOing it
14:04<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
14:05<frosch123>hmm, yes, looks like the orientation is not handled automatically
14:06<Elyon>yeah :)
14:06<Elyon>from not having toyed enough with ottd source ... X is SW<->NE, right?
14:07<frosch123>yes, though i would have said NE->SW (oriented) :p
14:07<Elyon>it's bidirectional though
14:07<@Alberth>positive X is to the left :)
14:07<Elyon>oh ... okay
14:08<Elyon>that seems rather opposite conventions
14:08<frosch123>for railtiles it does not matter, but the world coordinates go that way
14:08<frosch123>X is SW, Y is SE, Z is up
14:09<Elyon>W is time?
14:09<Elyon>hmm, okay. will keep that in mind; directions are southward
14:10<@Alberth>it happens when you assign the northern-most tile as (0, 0) :)
14:11-!-jjavaholic [] has joined #openttd
14:26<Eddi|zuHause>positive X is to the lower left
14:26<Eddi|zuHause>positive Y is to the lower right
14:26<Eddi|zuHause>openttd has a weird coordinate system that makes you break your wrist when trying the right-hand-rule
14:28<frosch123>you just need to sit on the other side of the screen
14:29<Eddi|zuHause>or we need map rotation :)
14:34-!-blathijs [] has quit [Ping timeout: 480 seconds]
14:38-!-blathijs [] has joined #openttd
14:38-!-smoke_fumus [~smoke_fum@] has quit [Ping timeout: 480 seconds]
14:50-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
14:53-!-jjavaholic [] has quit [Remote host closed the connection]
14:55-!-Plaete [] has joined #openttd
15:27-!-Wolf01 [] has joined #openttd
15:27<Wolf01>hi hi
15:30-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
15:32-!-smoke_fumus [~smoke_fum@] has joined #openttd
15:39-!-jjavaholic [] has joined #openttd
15:40<Elyon>mm, segfaults
15:44<andythenorth>well done
15:44<andythenorth>not an easy prize to achieve :)
15:45<Elyon>riiight :p
15:45<Elyon>so apparently hmm
15:45<Elyon>apparently I /need/ to use a spriteset for an item?
15:51-!-sla_ro|master [slamaster@] has quit []
16:04-!-Taede [] has joined #openttd
16:09-!-JacobD88 [] has joined #openttd
16:12-!-Plaete [] has quit [Quit: Nettalk6 -]
16:12-!-Myhorta [] has joined #openttd
16:16<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
16:17<Elyon>this has been discussed here: - but was there ever any consensus as to how to approach this issue?
16:17<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?
16:18<Elyon>slash realsprite?
16:18<frosch123>i guess comparing industries and stations the roles of sets and sprites inside sets are somewhat swapped
16:19<frosch123>for industries within a set you use construction stages by default
16:19<frosch123>while you swap graphics by switching the set
16:19<frosch123>for stations it's the other way around
16:19<Elyon>hmm, yeah, quite true
16:19<frosch123>the set is used for ther amount, while within the set you pick the graphics
16:19<Elyon>I'm just wondering what the nml syntax (the most important part) should be
16:20<Elyon>I'd rather not require `0x8000042D + index` of the grf developer
16:20<frosch123>well, techncially you can use 7 spritesets within one station layout
16:20<Elyon>if anything, I could just translate `spriteset(index)` to `ConstantNumeric(index)`
16:20<frosch123>but i guess it is also fine to restrict it to one
16:21<Elyon>how can you use 7 spritesets?
16:21<frosch123>in the adv. spritelayout you can specifiy a var10 value
16:21<frosch123>for each var10 value you can pick a different action2, i.e. a different spriteset
16:22<Elyon>ah, right. Well, do you have any thoughts on desired nml syntax?
16:22<frosch123>valid values for var10 are 0 to 7, but 2 is used for foundations, so effectively you only have 7 values available
16:22<frosch123>i am not really fluent in nml syntax :p
16:22<frosch123>is there an industry example?
16:23<frosch123>hmm, let's look on bundles
16:23<Elyon>there's an airport example
16:23<Elyon> <- I am currently overloading the spritelayout
16:23<Elyon>to work with stations as well
16:23<Elyon>the syntax is almost exactly the same, except for the pesky sprite resolving
16:24<Elyon>wat. indentation 1, that's new :p
16:24<frosch123>so, i think just allow the same references to spritesets, but fail if more than 7 are used
16:24<Elyon>hmm ... that'll take some magic to resolve, I think ...
16:25<frosch123>that file is the output of a c-preprocessor
16:25<frosch123>so you are lucky there are linebreaks :p
16:25<frosch123>i guess for a start it is also fine, if only 1 is allowed
16:25<Elyon>it'd be nice to support all 7 (or 8 if you feel like conflicting with foundations)
16:25-!-Pereba [~UserNick@] has quit [Read error: Connection reset by peer]
16:26<frosch123>well, the syntax would support it
16:26<Elyon>but yeah, for a start 1 could suffice. After all, NML has been around for 3+ years with /no/ support for stations :D
16:26<frosch123>so, it's not like it blocks something
16:26<Elyon>but the spriteset available depends on the v-- oh
16:26<frosch123>also, 3 years ago, there was no station set that required more than 1 set :p
16:27<frosch123>it 7 sets add-on is really new, only chips and the newest isr may use it
16:28<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
16:28<Elyon>I see
16:28<Elyon>hmm, I have a question related to var10/act1,2,3 chain etc. then
16:29<Elyon>so the act1,2,3 chain is resolved repeatedly until ... AH
16:29<frosch123>they form a decision tree
16:29<Elyon>nevermind, I thought for a moment there the var10 resolve flag was a property of the layout as a whole
16:29<frosch123>they are no imperative program code, that is run
16:29<frosch123>instead they are asked for a result for every question
16:30<Elyon>yeah :)
16:30<Elyon>so say I set a sprite to resolve with var10=1
16:31<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?
16:31<frosch123>the layout is resolved first
16:31<frosch123>the layout defines which var10 values need to be resolved
16:32<Elyon>right, hmm
16:32<frosch123>if the layout used var10: 0,3 and 7, then spritesets will be resolved for var10=0, 3 and 7 :)
16:32<Elyon>so ... lemme quickly jot down some syntax
16:32<frosch123>ideally the grf programmer would not have to check var 10
16:33<frosch123>but nml would generate the switch automatically
16:33<frosch123>i.e. the grf programmer only puts the spritelayout referecing the spritesets
16:33<Elyon>try, catch, /finally/: each sprite is drawn only once, correct?
16:33<Elyon>frosch123: yeah, I like this syntax
16:33<Elyon>it stays true to ind/airports
16:34<frosch123>and nml generates all from that: the action0, the layout callback, and the various spriteset results depending on var10
16:35<Elyon>so if I supply, say, 7 spritesets, nml should generate a `switch 0:set_0; 1:set_1; 3:set_2 ...` etc.?
16:35<Elyon>and warn/fail if more than 7 sets were requested?
16:35<frosch123>that would be awesome :)
16:36<Elyon>I shall make it so. First, though, I'll take your advice and implement it for /one/ spriteset
16:36-!-Taede [] has quit [Quit: He who can look into the future, has a brighter future to look into]
16:36<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
16:37<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)`
16:37-!-Taede [] has joined #openttd
16:38<frosch123>"sprite: wind_powerplant_set(0)" <- spritesets would be used like that
16:38<frosch123>so, i guess, just use the first one that is encountered
16:38<Elyon>so it goes act3 -> varact2(select_spriteset) -> act1(spriteset_selected) ?
16:38-!-Guest1054 [] has quit [Quit: leaving]
16:39<Elyon>then, another question: what goes in the `graphics` section of the station item, if the spritesets are selected exclusively from the layout?
16:39<frosch123>act3 -> all the switches from nml -> [ varact2(callback_id) -> varact(var10) -> act2 ]
16:40<frosch123>where the [ ... ] part is generated from the nml spritelayout
16:40<Elyon>yeah, sounds great
16:40<frosch123>in the graphics section you put "foundation_graphics", and as default the start to the "all the switched from nml"
16:41<frosch123>you still have to link the spritelayout to the item via switches
16:41<Elyon>I've linked it as a property `layouts` currently
16:41<frosch123>ideally there would be no property, but it would be auto-generated by nml
16:42<Elyon>no graphics property you mean?
16:42<frosch123>just like the callback-flags propery is generated depending on the stuff in the graphics section
16:42<Elyon>in nfo I usually just use a dummy act2 as the final act2 iirc, as the advspritelayout does the heavy lifting anyway
16:43<Elyon>and how would you link the spritelayout via switches? You can't switch between advspritelayouts, only re-resolve with var10 though?
16:46<Elyon>huh, doesn't have nml syntax :p
16:48<frosch123> <- i mean something like that
16:48<frosch123>^Spike^: why is there no longer a "forever" paste?
16:48<Elyon>I was wondering the same thing
16:49<frosch123>Elyon: how do you mean "you cannot switch between advspritelayouts" ?
16:49<Elyon>and ah, I was authoring a slightly more elaborate example, possibly for inclusion in the ancient issue related to nml stations
16:49<frosch123>callback 14 selects the spritelayout
16:49<Elyon>frosch123: you can't varaction2 -> station_advspritelayout
16:50<Elyon>I haven't looked at callback 14
16:50<frosch123>essentially you can do varaction2 -> spritelayout
16:50<Elyon>that's exactly what I said the opposite of
16:50<frosch123>that's what i mean with "varaction2(callbackid)" followed by "varaction2(var10)"
16:50<Elyon>and this works for advspritelayout as well?
16:50<frosch123>it's supposed to emulate taht
16:51<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
16:52<frosch123>the indexed layout then specifies the var10 to use to resolve the spritesets
16:52<^Spike^>ehm frosch123 let me fix that then
16:52<^Spike^>i blame update :D
16:52<^Spike^>they added an option that explains it
16:52<^Spike^>should be fixed now
16:52<frosch123>yup :)
16:52<^Spike^>btw also added squirrel highlighting thnx to Sylf on paste so
16:53<frosch123>oh, maybe sylf can also do a nml highlighter then :p
16:53<^Spike^>i shall say nothing about what i see
16:53<^Spike^>(love being admin sometimes :))
16:54<Elyon>ruby does an okay job of matching the nml syntax actually
16:54<Elyon>at least, it's what I'm using to highlight nml
16:54<frosch123>the nml repository has some syntax highlighting files and a generator for reserved words
16:54<frosch123>maybe that can be reused
16:54<Elyon>probably. there's no vim highlighting though
16:55<^Spike^>don't talk about vim highlighting
16:55*Elyon talks about vim highlighting
16:55<^Spike^>because i got fed up with having to do my powershell stuff for vmware using rdp i install a powershell vim highlighter :D
16:56<^Spike^>they do exist for some reason :)
16:56<^Spike^>and it's good enough to write my simple powershell stuff....
16:56<^Spike^>love having automatic migrations :D
17:02<frosch123>Elyon: i guess the difference to industry/object layouts would be that that the spritelayout would reference spritegroups instead of spritesets
17:03<Elyon>hmm ...
17:03<Elyon>(so var2(callback) -> var2advspritelayout overriding the stationprop advspritelayout?)
17:05<frosch123> <- so, more like that
17:05<frosch123>but, i guess for a first version that can be skipped as well
17:05<Elyon>hmm, I think I understand. I haven't used callback 14 before
17:06<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
17:08<Elyon>direct spriteset references from where?
17:09<frosch123>if nml puts those var0C and var10 varaction2 at the end, it would also magically allow the grf developer to use temporary storages
17:09<frosch123>since they would be shared between callback14 and the various var10 sprite resolves
17:09<Elyon>hmm, that seems ideal
17:10<frosch123>Elyon: spriteset references from the spritelayout, without intermediate spritegroup
17:10<frosch123>like in the earlier example
17:10<Elyon>implementing rudimentary station support seems easy enough. Supporting every NFO-supported use-case, however, does not
17:10<Elyon>ah, yes
17:11<frosch123>it does not look that rudimentary to me :p
17:11<frosch123>it rather looks like pretty much all to me :)
17:11<Elyon>all what?
17:12<frosch123>what "nfo-supported use-case" are you missing? :p
17:13<Elyon>multiple spritelayouts, for one
17:13<Elyon>and multiple spritesets in a layout, as another thing
17:14<frosch123>ah, i was only considering the syntax
17:14<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
17:14<frosch123>i think the syntax covers all cases, it can be implemented in steps of course
17:14<Elyon>of course
17:14<Elyon>I have a more complete example coming up, perhaps you can tell me if I've understood your suggestions properly
17:15<Elyon>ah, there's of course the issue that a station expects two spritelayouts
17:16<Elyon>one for each orientation
17:16<frosch123>hmm, so we need a layoutgroup?
17:16<Elyon>I don't know, maybe so
17:17<frosch123>layoutgroup layout1 { X: stationlayout1; Y: stationlayout2 }
17:17<Elyon>the thing is, you can't `switch` to just one spritelayout. It needs two or it segfaults
17:17<frosch123>but yeah, that makes it indeed more difficult
17:18<Elyon>well, I like the syntax for that, /but/ that introduces a new keyword
17:19<frosch123>it also does not quite fit with the var10 thing i suggested
17:19<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?
17:19<Elyon>well, why not?
17:19<Elyon>it'd still just be an action2-advspritelayout in the end
17:20<frosch123>the two spitelayouts could (and possibly very likely would) use different spritesets
17:20<frosch123>so the var10 chain also need to check orientation
17:20<frosch123>to know which spritelayout is actually used
17:21<frosch123>unless you separate the var10 values
17:21<Elyon>is that an issue?
17:22<frosch123>well, is there actually a variable to check orientation? :p
17:23<Elyon>I believe there is
17:23<Elyon>I seem to recall doing it, lemme check
17:25<frosch123>hmm, var40 bit 24 i guess
17:25<Elyon>how so?
17:26-!-gelignite [] has quit [Quit:]
17:26<Elyon>everything seems to flip based on orientation, I can't figure out how to actually /figure out/ orientation
17:27<frosch123>var40 contains the "tile", which i believe is also alternating
17:27<Elyon>`stationlayout`, `layoutgroup` `layoutpair` ... hmm.
17:28<Elyon>is there anything else that depends on a specific number of layouts?
17:28<frosch123>but, this is all quite weird, i am not sure anymore the current syntax is ideal :)
17:28<Elyon>possibly not. Hence; pre-implementation discussion :)
17:29-!-TomyLobo [] has joined #openttd
17:29-!-TomyLobo [] has quit []
17:32<Elyon>what was this splitting you mentioned?
17:32<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
17:34<Elyon>separating the var10 values
17:35<frosch123> <- at the end there is a "varaction2(var10)"
17:35<frosch123>which selects the spritegroup/spriteset
17:35<Elyon>hmm, yes
17:35<Elyon>but that depends on whether it's layout_x or layout_y
17:36<frosch123>for every used spriteset you need a different var10, though possibly you can also use the orientation
17:36<Elyon>as you said
17:36<frosch123>so, unless you completely separate the orientations with different var10 (0,1 for X, 4,5 for Y), you need to check orientations
17:37<Elyon>and I cannot see any way to check orientation
17:37<frosch123>nfo newgrfs would likely use the same spritegroups for both orientations, but different sprites inside them
17:37<frosch123>so, maybe that would also be an option
17:38<frosch123>maybe the orientation should just be a parameter to the spritelayout
17:38<frosch123>spritegroup1(0) -> spritegroup1(2*
17:38<frosch123>spritegroup1(0) -> spritegroup1(2*0 + orientation)
17:38<frosch123>or something
17:38-!-Quatroking [] has quit [Read error: Connection reset by peer]
17:38<frosch123>that would make it easier for nml and more close to traditional station grfs
17:39<Elyon>or inferred from the index into the layoutgroup
17:39<frosch123>if the spritelayout would have a built-in orientation parameter, nml could create two layouts from it
17:39<frosch123>with the orientation offsets already evalauated
17:40<frosch123>hmm, yeah, i guess i like that more than the "layoutgroup"
17:40<Elyon>so `spritelayout(station_layout_x, STATION_ORIENTATION_X) { ... }`?
17:41<Elyon>or ... I'm not sure I follow just yet
17:42<Elyon>so adding an optional parameter to the `spritelayout` instead of adding an entirely new block?
17:43<Elyon>(optional and useless for spritelayouts for other things than stations, but mandatory for stations)
17:44<frosch123>i somehow want to enforce that sprites for different orientations must follow each other in the spriteset
17:45<Elyon>hmm... why?
17:45<Elyon>that seems an odd uh ... index squatting
17:45<Elyon>it would make the syntax neater, but ...
17:46<Elyon>and what about sprites that are used identically in both orientations?
17:47<Elyon>enforcing realsprite duplication seems a bit weird to me - but I can see why you'd prefer that solution
17:47<frosch123>yeah, those two cases :) either same sprite, or sprites follow each other. but not entirely different spritesets for direction
17:47<Elyon>enforcing same sprite would be too limiting
17:47<Elyon>I think?
17:48<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
17:48<Elyon>hah, understandable
17:49<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
17:49<Elyon>still need a group though
17:49<Elyon>a layoutgroup I mean?
17:50<Elyon>or some way of coupling two spritelayouts together
17:50<Elyon>no, I see what you're getting at
17:51<Elyon>you'd only need one spritelayout which NML would duplicate with +1 offsets for Y-orientation
17:51<frosch123> <- not exactly nice looking, but may do the job
17:51-!-andythenorth [] has left #openttd []
17:52<frosch123>hmm, maybe instead of "WITH_ORIENTATION" there could be a constant offset for Y orientation
17:52<Elyon>+1 comes to mind
17:52<Elyon>and, why do you need the spritegroups?
17:52<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
17:52<frosch123>spritegroup is for the little/lots thingie
17:53<frosch123>but, well, optional :)
17:53<Elyon>okay. you can reference spritesets directly as well, right?
17:53<Elyon>how would this compile-time offset be specified?
17:53<Elyon>and how would the grfauthor specify it - per-sprite or per-grf?
17:55-!-JacobD88 [] has quit [Quit: JacobD88]
17:55<Elyon>minor suggestion:
17:56<Elyon>spritelayout sprite parameter `orientation_offset`, defaults to 1
17:56<Elyon>instead of the WITH_ORIENTATION/WITHOUT_ORIENTATION stuff
17:57<frosch123> <- next iteration
17:57-!-oskari89 [] has quit []
17:57<frosch123>ah, "orientation_offset" looks better indeed :)
17:58<frosch123>hmm, so about the little/lots thingie, that needs a cargo type
17:58<frosch123>let's see how vehicles do that in nml
17:58<Elyon>I don't think it is strictly impossible to have the offset be runtime-constant instead
17:59<Elyon>or even variable; you made a flag for that :p
17:59<Elyon>but that is pretty advanced stuff considering everyone and their mum will manage with offsets `0` and `1` probably
18:00-!-pxr [] has quit [Quit: Leaving]
18:00<frosch123>yup, so good enough for now
18:01<frosch123>ah, so vehicles use the cargo label in the graphics section
18:01<Elyon>so when NML spots a feature-4 spritelayout, it duplicates it and resolves the constant offsets?
18:01<frosch123>so, i guess we can expose the same for stations
18:01<Elyon>do you have an example for vehicle littlelots handy?
18:01<Elyon>yeah, consistency is key :)
18:02<frosch123> <- for vehicles it's "loading" and "loaded"
18:03<Elyon>ah, hmm!
18:03<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
18:03<Elyon>yeah, that figures :)
18:05<Elyon>so the first possible advspritelayout-resolving for a station is set as its prop 1A - all other spritelayouts are switched-into?
18:05<Elyon>as varaction2s
18:05-!-Suicyder [~Suicyder@] has quit [Quit: HydraIRC -> <- Organize your IRC]
18:07<Elyon> <- updated example from before
18:07<Elyon>without loading/loaded distinction
18:09<Elyon>(as you can see, ruby does an okay job of syntaxhighlighting - at least if you write comments as `//#`
18:12<frosch123>property 1A is a list of layouts
18:12<frosch123>callback 14 returns a index into that list (+1 for orientation)
18:12<Elyon>oh, ah
18:13<Elyon>so all station advspritelayouts are defined in prop1A?
18:13<frosch123>the propery is actually per station
18:13<frosch123>so, the spriteset needs to figure out, in which item it is used
18:13<frosch123>or rather the item needs to figure out, which spritelayouts it can reach, and add those
18:14<frosch123>so, not quite straight forward
18:14<Eddi|zuHause>something tells me the station spec is even more terrible than the rest of nfo...
18:14<Elyon>well, true. I haven't looked into NMLs resolving of relateds
18:14<Elyon>it is featureful, at least
18:14-!-zeknurn [] has quit [Remote host closed the connection]
18:15<Eddi|zuHause>half of the problem seems to be that it has a totally different handwriting than the industry/object/airport spec
18:15-!-zeknurn [] has joined #openttd
18:15<Eddi|zuHause>while trying to achieve most of the same things
18:15<Elyon>most things from ind/obj/air can still be leveraged with a bit of tweaking, though
18:15<frosch123>Eddi|zuHause: i think we solved that issue
18:16<frosch123>by figureing out how to emulate the industry behaviour for stations
18:16<Elyon>in the end, the syntax should feel consistent with the rest of NML and I think that's feasible :)
18:17<Elyon>hmm, to remove all my queued patches and rollback to remote tip, I just `hg qpop` all the patches, yes?
18:17*Elyon loves starting from scratch after gaining further insights
18:17<frosch123>qpop -a
18:17<Elyon>ah, wonderful
18:18<frosch123>"update -r qbase" may also work
18:18<Eddi|zuHause>it doesn't actuall forget all the patches so far, it just rolls back the working copy
18:19<Elyon>yeah, I manually removed the patches I didn't want and kept the few that aren't related to advspritelayouts
18:19<frosch123>there are (automatic) tags qparent:qbase:...:qtip
18:19<Eddi|zuHause>this is useful if you want to pull an update
18:19<frosch123>handy for log -rqparent:qtip and stuff
18:19<Eddi|zuHause>qpop -a; pull; update; qpush -a
18:20<frosch123>that's the lame way to do it though :p
18:20<frosch123>"hg pull --rebase" does a more powerful 3-way merge
18:20<Elyon>here we go
18:20<frosch123>though you need to know how to rebase and resolve conflicts interactively
18:20<Elyon>I'll get used to this eventually
18:21<Elyon>I just vimdiff
18:23<Wolf01>'night all
18:23-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:25<Elyon>oh, minor issue; GROUNDSPRITE_RAIL_X is 1012, while GROUNDSPRITE_RAIL_Y is 1011
18:26<Elyon>we could hardcode that check for 1012, but hardcoding magic numbers is neh
18:27<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
18:28<frosch123>hmm, or we swap X and Y
18:28<Elyon>also, another decision to make: NML syntax for naming station classes?
18:28<Elyon>that could also work
18:28<frosch123>so the "offset" is applied as "+ 1 - offset"
18:29<frosch123>bah, how stupid, why is Y < X :/
18:29<Elyon>so spritelayouts for stations are defined by their Y-orientation, and the X-orientation is generated from that?
18:29<Elyon>I don't know :(
18:29<frosch123>Elyon: objects also have classes
18:29<Elyon>frosch123: oh, I'll just copy whatever they do then
18:29<Elyon>if those classes have names, anyway
18:29<frosch123>not sure whether they do it the same though :p
18:30<frosch123>but they have a 4-byte identifier, and a name in the gui
18:30<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
18:30<Elyon>yeah, that is exactly the same for stations
18:31<Elyon>also, subtracting offset will confuse many a grf-author
18:31<Elyon>if they put the offset as '24' and it actually takes their spriteindex and subtracts 23
18:32<frosch123>so, "GROUND_SPRITE_RAIL_X" and "orientation_offset: -1" ? good enough for the first version i guess :)
18:33<Elyon>"GROUND_SPRITE_RAIL" suffices, I'd think
18:34<Elyon>but yeah!
18:34<Eddi|zuHause>you should probably completely abstract away this offset nonsense
18:34<Eddi|zuHause>i don't know...
18:34<Elyon>for groundsprite, sure - but for the other sprites?
18:34<Elyon>there are three very distinct cases really
18:35<Eddi|zuHause>let the programmer provide both orientations as one spriteset, or so...
18:35<Elyon>but that gets unwieldy and weird, actually
18:35<Elyon>0: same sprite for both orientations
18:35<Elyon>1: consecutive sprites for X and Y
18:35<Elyon>2: arbitrary offset between X and Y
18:36<Elyon>`1` being default
18:36<Elyon>it's as abstract as it gets, I think
18:36<frosch123>i would make "0" the default
18:36<Elyon>same sprite?
18:36<frosch123>that makes the "-1" less surprising
18:36<Elyon>but ... huh
18:37<Elyon>most grfs would use consecutive separate sprites for each direction I would think?
18:37<frosch123>well, actually, we should take a look at cats, what will turn out handy :p
18:37<Elyon>and we'll figure out a way to get rid of `ground { orientation_offset: -1; }` eventually :D
18:37<Elyon>haha :D
18:38<Elyon>well, all the platforms need orientation and all the cargo doesn't
18:38<Elyon>so there's a good mix of both cases in there
18:38<frosch123>hmm, how about a built-in function "rail_track_ground"
18:38<Elyon>but in general, when authors define stations they need orientation-specific sprites, I'd think?
18:39<Elyon>`rail_track_ground` for?
18:39<frosch123>which can be used inside the spritelayout instead of the groundsprite
18:39-!-glx [] has quit [Read error: Connection reset by peer]
18:39<frosch123>and provides the correct y offset, handles snow and stuff
18:39<Elyon>hmm, interesting
18:39<frosch123>but, well, nothing for the first version :p
18:40-!-glx [] has joined #openttd
18:40-!-mode/#openttd [+v glx] by ChanServ
18:40<Elyon>so `rail_ground` replaces `ground { sprite: GROUNDSPRITE_RAIL; orientation_offset: -1; }` entirely?
18:40<frosch123>i just suggest it, because ottd has quite specific expectations for the groundtile of station tiles with track
18:40<Elyon>what expectations are these?
18:40<frosch123>since ottd does the magic for railtypes
18:41<Elyon>ah, yes
18:41<frosch123>SplitGroundSpriteForOverlay expects either SPR_RAIL_TRACK_X, SPR_RAIL_TRACK_Y, SPR_RAIL_TRACK_X_SNOW or SPR_RAIL_TRACK_Y_SNOW
18:41<frosch123>the latter two for snow or desert (*sigh*)
18:42<frosch123>it's actually funny, how the default stations never handled snow :)
18:42<frosch123>that's why the newgrf have to deal with that :p
18:43<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
18:43<Elyon>like a catch-all groundsprite
18:44<Elyon>so, at least for stations and possibly for most/all other things, you'd just put `ground`
18:44<frosch123>well, the orientation_offset is already special for stations, so i guess there can be another "groundsprite_track" item or something
18:44<Elyon>or even leave it out and NML would supply a groundsprite always
18:45<frosch123>well, non-track station tiles would not use that
18:45<Elyon>why not?
18:45-!-Hazzard is now known as BiG_FISHBOT
18:45<frosch123>non-track station tiles can use whatever ground they like, they do not display anything from the railtype grf
18:45-!-BiG_FISHBOT is now known as Hazzard
18:46<frosch123>they would rather use one of GROUNDSPRITE_CONCRETE or GROUNDSPRITE_CLEARED etc
18:46<frosch123>or a custom one
18:46<Elyon>yes, that is true
18:46<Elyon>what is GROUNDSPRITE_CLEARED?
18:46<Eddi|zuHause>hm. there was something about the track becoming visible on transparent non-track tiles
18:46<frosch123>the dirt instead of grass
18:46<Elyon>oh right
18:47<frosch123>Eddi|zuHause: bug in the grf :)
18:47<Eddi|zuHause>i think newstations did that, but that may just have been old...
18:47<Elyon>well, wouldn't most stations (and spritelayouts in general) use `track` for train-accessible tiles and `GROUNDSPRITE_NORMAL` otherwise?
18:48<frosch123>Eddi|zuHause: most likely transparency at that time only affected houses
18:48<Elyon>blah, you're right
18:48<Elyon>no reason to do /all/ the work with NML
18:48<Elyon>meaningful defaults should suffice
18:48<Elyon>I like the idea of groundsprite_rail
18:48<Elyon>or track or something
18:48-!-Hazzard is now known as status
18:49-!-status is now known as Hazzard
18:49<Elyon>and ground { sprite: <num>; } otherwise :)
18:50-!-Hazzard is now known as Hazzard_
18:50-!-Hazzard_ is now known as Hazzard
18:50-!-Hazzard is now known as Hazzardkajkd
18:50-!-Hazzardkajkd is now known as Hazzard
18:50<Elyon>hi Hazzard, are you bored? :p
18:52<Hazzard>Eh, I'm having some irc troubles
18:55<Elyon>frosch123: <- does this syntax look ready to implement support for?
18:56<Elyon>oh, you wanted `orientation_offset` to default to `0`, so I need to specify it as `1` for the two platform `building`s
18:56<frosch123>ow, what to do with "yoffset" and "yextent" wrt. orientation?
18:56<frosch123>just swap them automatically?
18:57<Elyon>it already does that
18:57<Elyon>yoffset is actually xoffset in Y-orientation
18:57<Elyon>super easy
18:57<frosch123>what do you mean with "already"? your implementation?
18:58<Elyon>no, grf
18:58<Elyon>well, ottd
18:59<frosch123>i don't think so, what's the point of the layout pairs then?
18:59<Elyon>it interprets yoffset as if it was xoffset for the other orientation
18:59<Elyon>I've childsprited enough cargo to know :p
18:59<Elyon>or at least think I know
18:59-!-Progman [] has quit [Remote host closed the connection]
18:59-!-Hazzard is now known as BiG_FISHBOT
18:59<frosch123>weren't you using the default layouts for now?
19:00<Elyon>no, I've been using advspritelayouts exclusive
19:00<Elyon>I've never tried any other layouting than your advspritelayouts :D
19:00<Elyon>I have no idea how they work
19:01<frosch123>anyway, what's "loaded_threshold"?
19:01-!-BiG_FISHBOT is now known as Hazzard
19:01<frosch123>ok :)
19:01<Elyon>and tbh shouldn't NML just always use advspritelayout?
19:01<Elyon>should I call it lots_threshold instead? You mentioned vehicles call it loading/loaded
19:01<frosch123>looks fine to me, though i am sure there will be more bear-traps :)
19:01<Elyon>bear-traps inbound indeed
19:02<frosch123>lots/little and loaded/loading are different things
19:02<Elyon>the first one was to leverage Action2Layout objects without generating action2s
19:02<Elyon>oh my mistake
19:02<frosch123>sure, you can use the same name for the first version
19:02*Elyon renames to lots_threshold
19:02<frosch123>but it would be hard to explain to a new guy :p
19:02<Elyon>lots_threshold is probably better then
19:03<Elyon>API changes are not a favourite pastime of mine
19:03<Elyon>well they are, but I get ill-mannered comments about them
19:04-!-Hazzard is now known as BiG_FISHBOT
19:04-!-BiG_FISHBOT [] has quit [Killed ( (Nick change collision))]
19:04-!-Hazzard [] has joined #openttd
19:08-!-Myhorta [] has quit [Read error: Connection reset by peer]
19:09-!-Hazzard is now known as BiG_FISHBOT
19:09*Elyon renamed `station_class` to `class` and introduced `classname`, to be consistent with Object properties
19:09-!-BiG_FISHBOT is now known as Hazzard
19:13-!-Pereba [~UserNick@] has joined #openttd
19:16-!-Hazzard is now known as HazzardServer
19:17-!-HazzardServer is now known as Hazzard
19:21<Elyon>alright, I should at the very least have that example syntax working tomorrow
19:48<frosch123>Elyon: <- summary (i hope)
19:49<frosch123>i changed some details in the grf generation, which should make it easier, while not adding restrictions
19:50<frosch123>but, i think we still have some issue with different x/y offsets for orientations
19:55<frosch123>hmm, the older examples in that task do not address the orientation issue at all :/
19:55<frosch123>so, i guess this new syntax is at least better than the older ones :p
19:58-!-FLHerne [] has quit [Quit: There's a real world out here!]
20:01<Elyon>frosch123: okay this is good
20:02<Elyon>am I am fairly certain x/y offsets and extents are flipped for the second orientation. Will have to check the bounding boxes, how do I enable those again?
20:03<Elyon>oh. Okay :p
20:03<frosch123>flipping makes no sense for childsprites
20:03<Elyon>that's true I guess
20:03<frosch123>so, i very much doubt ottd does anything there
20:03<Elyon>well, if it doesn't, what should we do?
20:04<frosch123>the default layouts in table/station_land.h also do manual flipping
20:04<Elyon>I stand corrected
20:04<frosch123>i think nml generating the two layouts from one spritelayout is still the right thing
20:04<frosch123>but it may need more than the orientation_offset for the sprite
20:04<frosch123>not sure :)
20:05<frosch123>if everything fails, one could allow lists with two items [x value, y value]
20:05<Elyon>well, CATS should use a lot of the advspritelayout features, and I'm developing that while developing nml stations
20:06<Elyon>then one might as well just have two spritelayouts and a layoutgroup
20:06<frosch123>actually, thinking about it... for the position offsets those values are either constant, or if dynamic then completely different
20:06<frosch123>hmm, so i guess it should be done as for house properties
20:07<frosch123>various house properties allow a single value to make it the same for all tiles of a house
20:07<frosch123>or a array [ ] with a fixed amount of items
20:07<frosch123>that may be the right thing for the offsets
20:07<Elyon>how does that work?
20:08<Elyon>also, "Each station spritelayout creates two action0 items" ?
20:08<frosch123>yes, for X and Y
20:08<Elyon>or two action0s?
20:08<frosch123>yes, that :p
20:08<frosch123>the former
20:08<Elyon>yes, that makes more sense :D
20:09<Elyon>first I have to stop `spritelayout()` from generating an action2 though
20:11<Elyon>in fact, I have to catch spritelayout in the act of generating action2s and have it generate action0properties instead
20:11<Elyon>somehow. Hmm...
20:12<frosch123>well, they are not generated immediately, but rather collected, and dumped at the end
20:12<Elyon>hmm, yes, I will have to read quite a bit of the source to understand how it does that, I think
20:13<frosch123>similar as to sounds
20:13<frosch123>action2 can freely reference sounds
20:13<frosch123>and at the end they are dumped into a single action11
20:13<Elyon>ah, I will try to mimic that procedure, then
20:15<Elyon>except I need to intercept the station action0
20:15<frosch123>not sure it needs to be in the same action0
20:15<frosch123>but you somehow need to know the id of the first valid station :p
20:15<frosch123>but, i guess just assume 0 for now
20:16<frosch123>anyway, not sure what timezone you are in, but i am going to sleep :)
20:16<Elyon>UTC I think
20:16<Elyon>night :)
20:16-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
21:13-!-Buntunub [] has joined #openttd
21:28-!-glx [] has quit [Quit: Bye]
21:29-!-supermop [] has joined #openttd
22:26-!-luaduck_zzz is now known as luaduck
22:31-!-MJP [] has quit [Ping timeout: 480 seconds]
22:55-!-Biolunar_ [] has joined #openttd
23:00-!-supermop [] has quit [Ping timeout: 480 seconds]
23:02-!-Biolunar [] has quit [Ping timeout: 480 seconds]
23:07-!-quorzom [] has quit [Read error: Connection reset by peer]
23:27<Elyon>action2layouts collected, injected into action0s
---Logclosed Thu Jan 08 00:00:17 2015