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

---Logopened Thu Jan 08 00:00:17 2015
00:07-!-supermop [] has joined #openttd
00:25-!-Haube [] has quit [Read error: Connection reset by peer]
00:45-!-MTsPony [] has quit []
00:53-!-Pereba_ [~UserNick@] has joined #openttd
00:55-!-Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
00:55-!-Pereba_ is now known as Pereba
00:56-!-Eddi|zuHause [] has quit []
00:56-!-Eddi|zuHause [] has joined #openttd
01:08-!-Pereba_ [~UserNick@] has joined #openttd
01:10-!-Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
01:10-!-Pereba_ is now known as Pereba
01:15-!-APTX [] has quit [Ping timeout: 480 seconds]
01:24-!-Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
01:26-!-Pereba [] has joined #openttd
01:37-!-HerzogDeXtEr1 [] has joined #openttd
01:38-!-Pereba [] has quit [Remote host closed the connection]
01:38-!-Pereba [~UserNick@] has joined #openttd
01:42<Elyon>nml/actions/ #no sprites defined at all, that's not very much.
01:43-!-HerzogDeXtEr [~flex@] has quit [Ping timeout: 480 seconds]
01:47-!-Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
02:02-!-liq3 [] has quit []
03:18<^Spike^>for the ppl who want to know: nml is added @ paste of ottdc (Thnx to Sylf)
03:26<Elyon>:D :D
03:26<Elyon>wondarfull <3
03:31-!-smoke_fumus [~smoke_fum@] has quit [Quit: KVIrc 4.2.0 Equilibrium]
03:32-!-supermop [] has quit [Ping timeout: 480 seconds]
03:52-!-Yotson [~Yotson@2001:980:6ac8:1:c109:6eb9:2e41:3b6] has quit [Quit: .]
04:01<Eddi|zuHause>what on earth is a kix test?
04:01-!-Yotson [~Yotson@2001:980:6ac8:1:c897:194e:d5be:e9c4] has joined #openttd
04:15-!-supermop [] has joined #openttd
04:20<Supercheese>If you had never heard of Kix cereal or its annoying commercial, the comic would make little sense
04:20<Supercheese>commercial slogan*
04:21<@planetmaker>it's not exactly a word which one is exposed to, if not living in an English-speaking country
04:21<@planetmaker>emphasis on living
04:21<@peter1138>planetmaker, it's a US thing. I have no idea, and I live in an English-speaking country.
04:21<Supercheese>they spammed their television commercials like crazy for a few years here
04:22<@planetmaker>k, then make it even narrower :)
04:26-!-Flygon__ [~Flygon@] has quit [Read error: Connection reset by peer]
04:31-!-Flygon [] has joined #openttd
04:59-!-petern_ [~petern@2a02:cb0:1138:1:c842:cd7f:896d:6bf2] has joined #openttd
05:03<petern_> Damn at ^U not working
05:03-!-petern_ [~petern@2a02:cb0:1138:1:c842:cd7f:896d:6bf2] has quit []
05:03<@peter1138>Hexchat smells.
05:04-!-heffer [] has joined #openttd
05:05<@planetmaker>o/ dihedral
05:06<dihedral>hey there pm
05:06<V453000>landscape smells
05:07*dihedral smells nothing
05:14-!-MJP [] has joined #openttd
05:18<@planetmaker>landscape smells when inhabited by mamals
05:20<@planetmaker>I don't understand your problem with landscape, V453000 :) It's 100% dead easy. Just sprite replacement, nothing else
05:20<@planetmaker>Except shores and rivers :P
05:29-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Ping timeout: 480 seconds]
05:40<dihedral>V453000: make code some flow fileds - code different flowers on different hill slopes, i.e. slopes facing NE or SW ...
05:41<@peter1138>Don't forget about fileds.
06:10*planetmaker prefers filets ;)
06:10<V453000>I know I already got it all written down and prepared
06:10<V453000>but it is a lot of stuff simply :D
06:10<V453000>also WTF at the 4 rough flat tiles
06:12<V453000>even shores and rivers make more sense than that :D
06:13<@planetmaker>it's simply more variety
06:14<V453000>well sure that is absolutely awesome, but systematically among the sets of 18-differently-orientated-tiles it is quite a wtf
06:15<dihedral>who needs variaty? make all landscape tiles black!
06:15<dihedral>then you need not rotat anything either
06:16<V453000>XD valid point but it is nice to see where is a hill and where is not :P gameplay raizins
06:18<supermop>Supercheese: Kix had that slogan when my mom was a kid
06:20<dihedral>V453000: you would see when you start building :-P or look at the minimap
06:35-!-Klanticus [~quassel@] has joined #openttd
06:46-!-MJP [] has quit [Read error: Connection reset by peer]
07:07-!-sla_ro|master [slamaster@] has joined #openttd
07:09-!-frosch123 [] has joined #openttd
07:20-!-dreck [] has joined #openttd
07:25<NGC3982>dreck: Yo, bro. (-;
07:25*dreck pokes ngc with a map pointing to the real switzerland
07:25<dreck>heh heh ;)
07:25<dreck>hows you btw?
07:26<NGC3982>Let's fix that, actually.
07:26<NGC3982>I haven't really put any effort in NewGRF-to-map realism on the servers yet.
07:26-!-LadyHawk [] has quit []
07:27<dreck>heh well I wasn't going to mind it but didn't feel like joining yet when you were online too at the time :)
07:27<dreck>(just so you knew)
07:27<NGC3982>Oh, you didn't want to play with me? :P
07:27<dreck>btw ngc on the other hand I need to thank you as I never ever knew the swiss set was actually in a released nature...I still remember looking at the WIP forum for it some...umm...some time ago
07:28<dreck> not you, just in general
07:28<NGC3982>Aight. Well, i found it in the favourite-GRF thread on /r/openttd on Reddit.
07:29<NGC3982>The NewGRF name "SBB set v1.0b" doesn't really advertise a fantastic train NewGRF. :-)
07:29<dreck>well ngc..if you need to know the Crocodile is my favorite locomotive swizterland-wise .. and theres always most of the metre gauge things too :)
07:30*Elyon yawns
07:30<dreck>admittly the one other thing about their metre gauge system to me is that they still run "mixed trains" when such practice died out a long time ago in usa .. that is freight and passenger together
07:31<dreck>ngc..the big locomotive with flexible nose ends? its the one rated for 66kph with heavy trains early on
07:31<dreck> heres a real photo of it in its normal service day
07:32-!-Supercheese is now known as Guest1134
07:32<Elyon>frosch123: when the action 3,2 chain doesn't end in a sprite group, should I generate a spritegroup or an action2real?
07:32-!-Supercheese [] has joined #openttd
07:32<frosch123>what? you are awake again?
07:32<Elyon>I am awake again
07:33<NGC3982>dreck: Oh! I like that.
07:33<Elyon>0.005 kibihours of sleep ought to be enough for everyone
07:34<frosch123>Action2Real is a class in nml.actions, what is spritegroup?
07:34<frosch123>there is nothing like that in nml.actions
07:35<Elyon>no, a spritegroup is just a special action2?
07:36<frosch123>i think you need to use create_spriteset_actions()
07:37<Elyon>the option is either to generate a spritegroup when a spriteset is referenced, or to allow FEAT_STATIONS items to reference spritesets directly
07:37<frosch123>it takes a ASTSpriteGroup and returns a action
07:37<Elyon>well feature 0x04 doesn't "support" spriteset actions by default, though it's an eeeasy addition
07:37<frosch123>referencing spritesets in the item makes no sense?
07:38<Elyon>it's just a shorthand for a spritegroup with 1 entry?
07:38-!-Guest1134 [] has quit [Ping timeout: 480 seconds]
07:38<frosch123>i think i don't understand you :p
07:40<Elyon>hmm ... should nml station item switch chains always end in explicit spritegroups?
07:40<frosch123>for the graphics items: yes
07:41<Elyon>that seems unwieldy in the case where the station does not change its graphics based on little/lots
07:41<frosch123>though yesterday we considered a short-hand for referencing a spriteset, which would generate a one-item spritegroup in-between
07:41<Elyon>some things already provide this shorthand I believe?
07:42<frosch123>in current nml? no
07:42<frosch123>i think vehicles always have to use a spritegroup
07:42<frosch123>other features do not have such a hing
07:43<dreck>ngc btw heres one interesting photo, some passengers, one empty flatcar, and a full load of timber to transload to the sbb line at some later station :)
07:43<Elyon>frosch123: ah, hmm, err
07:44<Elyon>frosch123: how do you explain the `action2.create_spriteset_actions` function then? :p
07:44<dreck>anyway what're you doing atm ngc? :)
07:44<Elyon>and specifically, it's description: "Create action2s for directly-referenced sprite sets"
07:44<V453000>excellent, 4864 x 29440 px sprite sheet
07:45<Elyon>you will soon hit gigapixels
07:45<V453000>more like holyshitpixels
07:45<V453000>NEED MOAR
07:46<V453000>actually I could put more in there, yeah
07:46<frosch123>Elyon: huh? there is create_spriteset_actions for vehicles, and there is make_simple_real_action2 for cargos (i believe)
07:47<frosch123>stations have to use create_spriteset_actions, because that is what newstations expects
07:47<Elyon>frosch123: hmm ... yes. and that takes a spritegroup
07:48<frosch123>create_spriteset_actions otoh is just some loop, which calls make_simple_real_action2 again
07:48<frosch123>so, you can still invent some dummy-spritegroup when referening only one spriteset
07:49<Elyon>yeah ... but, for example, objects support referencing layouts instead of spritegroups
07:49<frosch123>yes, but objects do not use action2real
07:49<frosch123>but action2layout
07:49<Elyon>yes, I'm just thinking about the nml syntax here, not the actual implementation
07:50<Elyon>oooh, wait, yes
07:50<frosch123>well, in that case spritelayouts of stations should be allowed to both reference single spritesets and spritegroups
07:50<frosch123>where spritegroups is the normal case for little/lots
07:50<frosch123>and spriteset is a shorthand for ignoring little/lots
07:50<frosch123>which implicitly generates an intermediate spritegroup
07:51<Elyon>yeah, I had it all tangled up
07:51<Elyon>item(FEAT_STATIONS) graphics must end in a spritelayout, yes?
07:51<Elyon>and each spritelayout generates corresponding action2s to the referenced spritesets and spritegroups
07:52<Elyon>where if there are referenced spritesets, dumb spritegroups are just generated?
07:52<frosch123>yes, plus the callback for the action0 spritelayout index
07:52<Elyon>yes, yes, all that
07:53<Elyon>but it will eventually end in a spritegroup/"spriteset-as-group"
07:53<Elyon>like, each of them?
07:53<Elyon>depending on cb14 it'll be the relevant spritegroup
07:54<Elyon>oh, and I meant to ask - does copying 1A property with 0A property work? If so, are you really sure you want the first station to define /all/ layouts regardless of their relevance to that station, and subsequently copy /all/ these layouts to /every single station/?
07:55<frosch123>yes, 0A works for 1A
07:55<frosch123>i think using the same layouts for all stations makes the implementation easier
07:55<Elyon>less neat output, though
07:55<frosch123>there is no real limit on the amount of layouts (32k i believe)
07:56<frosch123>and you do not run into issues with nml-switches being shared between stations
07:56-!-supermop [] has quit [Ping timeout: 480 seconds]
07:56<Elyon>hmm ...
07:56<frosch123>but, sure, if you can deal with shared switches, and generate matching layouts :) sure it would be better :)
07:56<Elyon>so let's say switch3->switch2->switch1->spritelayout
07:57<Elyon>but switch2 branches differently depending on the station?
07:57<frosch123>no, two items reference switch2
07:57<Elyon>ah, yes, okay
07:57<frosch123>so if you have spirtelayout1, ... spritelayout5: one item may use layout1 to 3, and another item may use layout2,4,5
07:58<Elyon>[station0, station1] -> switch2 -> switch1 -> [layout0, layout1, layout2, layout3]
07:58<Elyon>this still means all four layouts are relevant for stations 0 and 1
07:58<frosch123>since the cb14 result is shared, you either have to make sure that all layouts have the same number for the items, or you need to duplicate the a123 chains, so that you can return different layoutsids
07:58<Elyon>so station0 gets prop1A, station1 gets prop0A unless it has more layouts that station0 doesn't have?
07:58<Elyon>hmm, good point
07:59<frosch123>ah, true, there is also an intermediate solution :) only share spritelayouts accross items which share some layout
07:59<Elyon>or allocate a register per station
08:00<Elyon>frosch123: ah, hmm, yes ... virtual layoutgroups, of sorts?
08:00<frosch123>however, while this is some detail: a grf developer can also disable a item by wrapping it inside a "if"
08:00-!-Suicyder [~Suicyder@] has joined #openttd
08:00<Elyon>I just think it'd be neater to only have station spritelayouts that can actually be reached for that station ... but with shared cb14 results, that would require a register offset or something
08:01<frosch123>in that case this station cannot be used for the original spritelayout definition
08:01<frosch123>but meh, i would ignore that for now
08:01<Elyon>or we could just set 1A property for every station :D worst of both worlds
08:01<Elyon>*set 1A prop identically
08:01<frosch123>well, it would still be un-noticable in a 32bpp zi4 set :p
08:02<Elyon>? what do you mean unnoticable?
08:02<frosch123>what do a few kilobyte more matter to a 150MiB grf?
08:03<Elyon>I am more worried about how ottd handles, say, 5,000 layouts in prop1A
08:04<frosch123>they are copied more or less unmodified onto the heap
08:04<Elyon>whether it truly is a `switch` statement in the ottd source; a loop would have a noticeable impact I would think
08:04<frosch123>while property 1A may actually share the pointers
08:04<frosch123>hah, not even that, 0A copies the data, nothing is shared
08:05<Elyon>ah, I guess if it's just `layout = layoutpointers[index]` then that should be fine
08:05<frosch123>so, duplicating 1A or using 0A makes no difference for ottd
08:05<Elyon>haha, okay. Well, using 0A is neater, 1A is easier
08:05<Elyon>well not really
08:06-!-LadyHawk [] has joined #openttd
08:07<Elyon>for index, action0 in enumerate(a for a in actions if isinstance(a, Action0)): # prop[1A] = layout if index == 0 else prop[0A] = action0s[0]
08:07<Elyon>and then some conditionals/tempvars to handle iffed-out layouts
08:08<Elyon>ORRR just set prop[1A] for every station and that magically makes iffing-out station items work
08:08<Elyon>slightly/quite bigger GRF though
08:09<Elyon>but I see the appeal of having every layout available to every station so we don't need to mess with cb14 offsets
08:09<Elyon>every virtual layoutgroup, that is
08:12<Elyon>and yes, it seems range(0, 0x7FFF) is available for cb results - so, that amount of /real/ spritelayouts, ie. half that amount of our orientation-independent spritelayouts
08:13<frosch123>well, i do not expect that much variety in layouts :p
08:13<Elyon>I do :p
08:13<frosch123>so, if grfs end up with lots of layouts, i would rather look into detecting duplicates
08:13<Elyon>I might leverage the fact that I can have 16384 layouts
08:13<frosch123>why would you have different layouts?
08:14<frosch123>using different spritesets in a layout do not change it
08:14<frosch123>and using different positions is very unlikely i think
08:14<Elyon>I could have the intended CATS layout variation in prop1A instead of in action2random?
08:15<frosch123>i think when using a offset register for the sprite, every stationgrf should get away with less than 20 layouts
08:15<Elyon>yes, that's what I have been doing until now
08:15<frosch123>anyway, no need to deal with that unless it becomes an issue :)
08:16<Elyon>but it would simplify a lot of things if I had, say, 256 layouts of cargovariations - then I would just have to set the spriteregister to the cargotype and the layout would handle the rest
08:16-!-MJP [] has joined #openttd
08:17<Elyon>so, in the end - "all prop1A" or "just one prop1A and the rest prop0A"?
08:17<frosch123>yes, that is one offset to the spriteset
08:17<frosch123>but the same layout in all cases
08:18<Elyon>cargosprite is dependent on a number of things, but some of those things could be in layouts as well
08:19<Elyon>for example, each cargotype has 8 variations which each have 4 sizes
08:20<frosch123> <- don't you mean something like that?
08:20<Elyon>selecting the variation combinations of the 8 (or even 16) cargospaces on the station tile can be done at compile-time with prop1A
08:20<frosch123>different sprites for cargos, selected via a register
08:20<frosch123>but it only needs one layout
08:22<Elyon>if it only has one layout (as I have been doing in the past), then with CATS we have to have an action2random for each 8 bits of randomness (8 bits should suffice), BUT that action2random needs to choose between 256 action2var that set the registers
08:22<Elyon>and /these/ action2var would each become more complex if they need to both determine the size and set the cargovariant
08:22<frosch123>no idea what you try to achieve, but randomaction is not the only method to do random
08:23<frosch123>you can access the random bits as variable "random_bits" and directly use it in computations
08:23*Elyon thinks
08:23<frosch123>sprite: front_sprites(2 * (LOAD_TEMP(0) + (random_bits >> LOAD_TEMP(1)) & 0x3));
08:23<frosch123>select cargo via register 0
08:24<frosch123>four variations per cargo type
08:24<frosch123>selected via random bits selected by register 1
08:24<Elyon>no, 32 variations per cargo type
08:24<frosch123>well, "& 1F" then :)
08:24<Elyon>8 completely random variations, each with 4 completely cargoamount-specific sizes
08:25<Elyon>using prop1A it would be possible to split the 8variations to compile-time layouts, and only use action2s (not action2randoms) to specifically determine cargoamount and set the cargosize by that
08:26<Elyon>I don't know, `compile-time` is a plusword in my book
08:27<Elyon>this is an oddly specific use case though
08:28<Elyon>of course, all this can be achieved with just /one/ spritelayout and a few somewhat more complex action2var expressions
08:28-!-MJP [] has quit [Quit: That's all folks!]
08:28<Elyon>I just figure indexing into spritelayouts is faster than a randomly-based branch
08:28<Elyon>especially for large amounts of layouts vs large amounts of random-branches
08:30<Elyon>oh, right, I didn't need that random-branch as I can access the randombits directly in an action2var
08:30<Elyon>which also removes the virtual limit of 256layouts for a single var2random
08:31<Elyon>at the expense of becoming more runtime than compiletime resolving of graphics
08:31<frosch123>as said, you do not need var2random
08:31<frosch123>you can use random_bits in a regular switch
08:31<Elyon>hence my correction
08:31<frosch123>or inside computations
08:31<Elyon>but that's more runtime computations
08:32<frosch123>i consider "var2random2" a deprecated thing, it's only needed for rerandomisation
08:32<Elyon>I guess I shouldn't worry about performance until it becomes an issue
08:32<Elyon>my previous question still stands, though;
08:33<Elyon>"prop1A for the lot" => simpler implementation, automagic item if-skip handling
08:34<Elyon>"prop1A for one and prop0A for the rest" => complex implementation, care must be taken to support if-skip
08:35<Elyon>ottd does the copying anyway, so the only reason not to stuff every related `virtual spritelayoutgroup => actual spritelayoutlist` into prop1A for every station would be considerations of GRF size
08:39<Elyon>each spritelayout can use 7 different spritegroups, but you can create an almost-arbitrary amount of spritelayouts, yes?
08:40<Elyon>(sorry about the incessant monologuing, I would just like to make sure I understand as much as possible of the desired specs before I implement them)
08:41<Elyon>for example I didn't see your suggestion/arguments for each station containing every layout, so right now each station only gets its related layouts in prop1A
08:42<V453000>this chat is more wild than usual XD
08:42<Elyon>I wanted the cats grfid as 0xCA57CA75
08:43<Elyon>but that's high ascii so :(
08:44-!-MJP [] has joined #openttd
08:45<Elyon>my two cents: each station gets every single relatedness-grouped layouts so cb14 doesn't need to be offset for any stations using that same virtual layoutgroup
08:45<Elyon>in prop1A
08:46<V453000>we cant use that ID? :(
08:46<@planetmaker>hey ho
08:46<@planetmaker>Elyon, no problem with high ascii grfIDs
08:47<Elyon>oh. Well in that case, how do I insert byte literals in stringliterals in nml(literals literals)
08:47<Elyon>and hay hieh
08:48<Elyon>oh, lowercase hexdigits
08:48<Elyon>haha, nml does not agree; value for prop8 must be of length 4
08:49<Elyon>probably just a sanity check
08:49<Elyon>slash assert
08:49<frosch123>Elyon: in addition, every spriteset can contain an almost-arbitrary amount of sprites
08:50<Elyon>frosch123: well, do we want to encourage a specific way of separating data, or equally show love and support for both single-spriteset and multi-spriteset layouts?
08:51<frosch123>well, from a performance pov, less spritesets is better :p but, well, performancy is hard to predict
08:51<Elyon>I guess implementing multi-spriteset inherently also implements single-spriteset
08:51<frosch123>in any case, usually stations are not the performance bottle neck
08:51<Elyon>and it shouldn't be too bad, really
08:51<Elyon>V453000: we could be using two, though
08:51<frosch123>stations hardly do anything if not visible
08:52<frosch123>so, they do not scale with map size like other stuff
08:52<Elyon>frosch123: stations will be the performance bottleneck once CATS is released
08:52<@planetmaker>does it work with "\CA\75\CA\75" ?
08:52<Elyon>pm: no
08:52<@planetmaker>I wonder then why firs works with grfid: "\F1%\00\05";
08:53<Elyon>I've been setting station classid this whole time
08:54<Elyon>although to be honest that should have been evident from "Value for /property 8/ must be of length 4"
08:54<frosch123>planetmaker: is the "%" instead of "\25" a left-over from the nfo->nml conversion?
08:55<frosch123>it does not look like a human would write it that silly
08:55<Elyon>although interestingly grfid is set in /action 8/
08:55<@planetmaker>I've no clue really
08:55<Elyon>\ca\75\00\00 could work as well
08:56<@planetmaker>Choose whatever you like really... and be aware that some people disagree with that :P
08:57<V453000>oh ca
08:57<V453000>yeah we need to start the grf name with ca
08:57<Elyon>and the award goes to V453000
08:57<Elyon>75 is ts in 1337
08:57<V453000>just to fill you in, there has been awesome drama/war over grf ID starting with CA previously XD
08:57<Elyon>and then we can have 65536 distinct grfs in the CATS name
08:57<V453000>CAnadian bullshit privilegez! :D
08:58<Elyon>not that I think we ever need more than just CATS
08:58<V453000>yes! :D
08:58<@planetmaker>V453000, "CAXX" != "\CAXXX"
08:58<V453000>XD k
08:58<V453000> /care anyway :P
08:58<Elyon>and you don't think they would lay claim to both "CA" and "\CA" prefix?
08:58<Elyon>had they only known
08:59<Elyon>frosch123: I'll just set prop1A for every station for now
08:59<@planetmaker>Elyon, 256^3 grfIDs are not enough. So sure they would
09:00<@planetmaker>actually: did
09:00<Elyon>CA prefix is only 256^2 IDs though
09:00<@planetmaker>yup, I know
09:00<Elyon>who cares, it's grfid anyway. It's supposed to be unique and that's it
09:04<Elyon>frosch123, oh and I will initially allow referencing spritesets from stationlayouts in case the grfauthor doesn't need little/lots distinction and doesn't want to deal with/write unwieldy dummy spritegroups
09:05<Elyon>I'm hoping someday to have those of you with /real/ insight tear my patches apart :D
09:05<Elyon>also, is the `"string %s interleaving" % format` python3 only, seeing as you haven't been using it in nml before?
09:06<frosch123>no, that rather looks like python2
09:06<frosch123>nml is python 3, which uses {} instead of %s
09:06<Elyon>what's the benefit of {} over %?
09:06<Elyon>I've been using % for ease-of-use
09:07<frosch123>no idea, albert has more insight into pythoni
09:07<SpComb>{} does slightly more things than % does
09:07<frosch123>but %s looks like c, it specifies the type of the argument, though that is known anyway
09:07<frosch123>{} makes it easier to group various formatting modifiers
09:08<SpComb>it can also do attribute/index lookups
09:08<Elyon>yet nml uses `{:d}` liberally :p
09:08<Elyon>anyway, I'll be using {} then
09:09<Elyon>and how do we feel about list/set comprehension?
09:10<Elyon>I've been using them extensively so far
09:16<frosch123>albert is a fan of them, so i believe him :)
09:17<Elyon>makes it super concise to collect all station action0s, at least
09:17<Elyon>or action3s for that matter
09:17<Elyon>also, I went with injecting the 1A prop into the current action0 instead of creating a new action0. It seemed neater.
09:25-!-liq3 [] has joined #openttd
09:30-!-MJP [] has quit [Quit: That's all folks!]
09:32<Elyon>frosch123, I had a /crazy/ idea
09:32<V453000>that sounds dangerous
09:32<frosch123>coding a animal-named station grf?
09:33<Elyon>you know how orientation_offset, orientation_xoffset, etc. gets unwieldy?
09:33<Elyon>I propose a new block (tentatively named `flip`) for spritelayoutsprites:
09:34<Elyon>the properties of `flip` are property offsets for the flipped layout
09:35<Elyon>so `flip { xoffset: -16; }` translates to `xoffset - 16`
09:36<Elyon>although xoffset and yoffset are swapped automatically for building sprites
09:37<frosch123> <- i also wondered about that, using [] may match more with nml houses
09:37<Elyon>oh okay, that is even better then
09:37<Elyon>consistency is key, etc.
09:38<frosch123>also, i think that these offsets are either compile-time constant, or completely differently computed for orientations
09:38<frosch123>so, when using [], it does not need to support variables
09:38<frosch123>but could blame the user to evaluate direction
09:39<frosch123>alternatively the entries [a,b] could use different registers for a and b, which are computed always, just the x/y layouts only use one of them
09:39<Elyon>hmm, so for each property of a sprite, [x, y] indicates the absolute value for orientation x and y, respectively?
09:39<frosch123>yes, that works fine for the offsets
09:40<frosch123>it does not work well for "sprite" and "palette" though :p
09:40<frosch123>palette is unliekly to ever depend on orientation though
09:40<frosch123>so, one could just stick to "orientation_offset" for "sprite", and use [] for all other items
09:41<Elyon>hmm ...
09:41<Elyon>or even
09:41<Elyon>sprite_offset: [0, -1]
09:42<frosch123>hmm, that's an interesting option as well
09:42<frosch123>particulary because of the spritegroups
09:42<frosch123>adding a () parameter to spritegroup references looks weird, since the parameter does not select the spriteset
09:42<frosch123>but is rather passed no to the spritesets
09:43<frosch123>so, detaching the parameter entirely from the spriteset/spritegroup reference could be a nice solution
09:43<Elyon>hmm, so it'd be ...
09:44<Elyon>sprite: super_awesome_spritegroup; sprite_offset: [14, 15];
09:44<Elyon>or even just `offset`
09:44<Elyon>instead of sprite_offset I mean
09:45<Elyon>`sprite_offset: [x, y]` is probably easier to make runtime-evaluatable as well
09:46<frosch123>yup, looks nice
09:46<Elyon>since it's just a pseudoproperty that sets sprite:
09:46<@planetmaker>what's that sprite offset?
09:46<frosch123>it selects the sprite from the spriteset
09:47<frosch123>that stuff works different to industries/objects because of the little/lots thingie
09:47<Elyon>frosch123: since it is a property of a sprite, the "sprite_" prefix seems redundant
09:48<frosch123>there is already xoffset, yoffset and zoffset, so "offset" may look weird
09:48<Elyon>not really
09:48<frosch123>maybe we can find a completely different word, not using "offset" :)
09:48<Elyon>it can be read as 'sprite.offset, sprite.xoffset, sprite.yoffset' etc.
09:49<Elyon>in my opinion, `sprite.offset` is pretty clear
09:49<Elyon>sprite: GROUNDSPRITE_TRACK; index: [0, -1]
09:49<Elyon>I don't know ...
09:49<Elyon>makes more sense to call it index for spritegroups/spritesets though
09:49<frosch123>it's only a name, time will tell what goes fluent
09:50<frosch123>i like "index"
09:50<Elyon>(sp: dependent?)
09:52<@planetmaker>hm... undecided :)
09:54<Elyon>I'll call it index for now. Updated example:
09:54<Elyon>pm: it's not just for spritesets though, as other Expressions are supported as well
10:13-!-Haube [] has joined #openttd
10:17<Elyon>so, support for every spritelayout sprite property as [x, y]?
10:22<Elyon>(for stations only of course)
10:25-!-Suicyder [~Suicyder@] has quit [Quit: HydraIRC -> <- IRC with a difference]
10:35<Elyon>I wish nml would print stacktraces on internal errors
10:36<frosch123>there is a "DEBUG" variable at the top of
10:37<frosch123>you need to set that one
10:37<frosch123>developmode = False # Give 'nice' error message instead of a stack dump. <- that one
10:37<frosch123>though there is also a command line option to enable it
10:42<Elyon>now you tell me :D
10:44<frosch123>i also only found it somewhen :)
10:45<Elyon>oooh, --debug prints the AST (which I just now figured maybe stands for abstract syntax tree?)
10:45<Elyon>no more compiling to NFO and checking the results myself
10:45<Elyon>wait, the AST is just ... nevermind
10:50<Eddi|zuHause>there is the -s switch if you want stacktraces
10:53<Elyon>I found it, thanks! :)
10:53<@planetmaker>helau for nmlc --help :P
10:54<frosch123>planetmaker: that does not help, once you tried "--debug", it's to scary to try the rest
10:54<Elyon>I did find it through --help though
10:55<Elyon>| grep debug was a red herring
10:56<frosch123> <- btw. i started collecting bollocks again
10:57<frosch123>i feel like there was more here or on the forums, but i did not find particulary much
10:58-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
10:58-!-mode/#openttd [+o Alberth] by ChanServ
11:01<Rubidium>maybe something about the bit 8 for articulated vehicles?
11:02<Rubidium>wasn't there something that you can only use vehicle id 0..127 for articulated vehicles?
11:02<frosch123>haha, we extended that in version 8 already :p
11:04<@planetmaker>:) 8k (or 16k?) articulated vehicles right now
11:06<@planetmaker>frosch123, what about views for vehicles instead of subtypes?
11:06<Eddi|zuHause>i think it's 16k
11:06<frosch123>there is a separate unwritten page about that :p
11:06<@planetmaker>they would have the explicit limitation that nothing can query it
11:06<Eddi|zuHause>but i' not sure anymore
11:07<@Alberth>assume 8k, it can only get better :)
11:07<Eddi|zuHause>should be 14 bits plus one "reverse" bit
11:07<frosch123>i also did not add the "vehicle sandbox" thingie, which would remove all the purchase list vehicle callbacks, and simulate the full articulated chains in the purchase list :)
11:08<Eddi|zuHause>planetmaker: i don't think views need "can't be queried", just "can't be changed after purchase"
11:08<frosch123>it's not really a incompatible change
11:09<Eddi|zuHause>frosch123: well, if it's tied to a GRF version, then you can know when to omit all the purchase list branching
11:09<@planetmaker>but it would be incompatible to drop the subtypes :P
11:10-!-gelignite [] has joined #openttd
11:10<Eddi|zuHause>frosch123: when it's not tied to a version, then you must put in purchase list stuff, even though it won't be queried
11:10<Elyon>hmm... regarding spritelayout-sprite-property-as-array, should I check `isinstance(value, Array)` and validate based on that, or just `if not isinstance(value, Array): value = Array([value])`, validate each entry (one or two entries), and then `if len(value.values) == 1: value = value.values[0]` ?
11:11<Elyon>it's the easiest way to implement sprite-property-as-array, but it seems a bit hack-ish
11:11<@Alberth>s/a bit//
11:12<@Alberth>I don't know what you ask in terms of NewGRF, but in terms of Python, "isinstance" is considered bad style
11:12<Elyon>I can also repeat the validation code for each entry if it is an array, but that seems a bit non-DRY-ish as well
11:12<Eddi|zuHause>Elyon: have you looked at other lists, like cargo refitting?
11:12<Elyon>Alberth, well NML is littered with isinstance so I figured it was the go-to check
11:12<frosch123>houses have several properties in the item, that can be set as array,or as single value
11:13<Elyon>frosch123, Eddi, I didn't even consider that. How terribly ignorant of me, my apologies. Thanks!
11:13<@Alberth>Elyon: yes, it is :( It was written by someone learning Python :)
11:13*Elyon is learning python
11:14<Elyon>so a try/catch or what?
11:14<Elyon>what is the pythonic way of conditional branching by object class?
11:15<Elyon>if hasattr(attr_to_look_for) ?
11:16<Eddi|zuHause>basically, yes. you would want to check whether the object "implements a protocol"
11:17<Elyon>I've noted that as TODO, now
11:17<@Alberth>might be interesting
11:18<@Alberth>in general, you should know what properties the thing you have can do, and use it as such
11:19<@Alberth>that makes it possible to give you any object I want, as long as I provide the capabilities that you need/assume
11:19<@Alberth>if you do explicit object-type testing, such code will fail
11:19<Elyon>Houses and Vehicle refitting have it easy and are not of use to me: neither of them has any properties that support both array and non-array values
11:20<Elyon>Alberth: that makes much-a sense-a
11:20<Eddi|zuHause>for my taste, python lacks a few builtins to check for protocol compliance
11:20<frosch123>Elyon: houses look like they convert single values to arrays in all cases
11:20<Elyon>frosch123: hmm
11:21<@Alberth>either always supply an array, by wrapping single obvjects into an array before the call, or make 2 methods, one for arrays and one for non-arrays
11:21<frosch123>there is 'multitile_function
11:21<frosch123>there is 'multitile_function', which is set to 'mt_house_same' or 'mt_house_zero'
11:21<@Alberth>ie know what you get without needing to test
11:22-!-quorzom [] has joined #openttd
11:22<Elyon>Alberth: that was my preferred approach, really, except converting back to a single value to not have to recode every single reference to spritelayout properties in the entirety of NML
11:22-!-dreck [] has left #openttd []
11:23<Elyon>I can do that but I doubt it'll make for a very nice patchset, especially considering my ~5 days of experience with python
11:24<@Alberth>well, you can't stop a river in one day, so perhaps your solution is the best temporary solution.
11:25<@Alberth>just pointing out the way of the python to you in an ideal world
11:26<Elyon>and that is much appreciated
11:26<Eddi|zuHause>what kind of saying is that? :p
11:26<Eddi|zuHause>have your people tried to stop rivers? :p
11:26<@Alberth>sea counts too? we did that
11:28-!-Kurimus [] has quit [Ping timeout: 480 seconds]
11:30-!-Klanticus_ [] has joined #openttd
11:30-!-Klanticus [~quassel@] has quit [Ping timeout: 480 seconds]
11:33-!-Elyon is now known as Guest1161
11:33-!-Guest1161 [] has quit [Read error: Connection reset by peer]
11:33-!-Elyon [] has joined #openttd
11:34<Elyon>there goes my backlog
11:35<Eddi|zuHause>most sane clients allow you to log into a file
11:36<Elyon>I don't like keeping logs anywhere but in ram
11:43<@Alberth>the Internet will keep it for you :)
11:46<Sacro>i miss that place
11:47-!-Kurimus [] has joined #openttd
11:49-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
11:51-!-Pensacola [] has joined #openttd
11:53-!-TheMask96 [] has joined #openttd
11:58-!-oskari89 [] has joined #openttd
11:58<Elyon>uh, so
11:59<Elyon>childsprite with xoffset < 0? Are grfauthors expected to 2-complement the offset themselves?
12:00<@Alberth>unless nfo has a unary -, yeah, I'd expect so
12:01<Elyon>I meant in nml
12:01<Elyon>it's a one-line fix to allow the childsprite offsets to be negative ... which I believe ottd supports. In fact, iirc ottd assumes any value higher than or equal to 0x80 for pixeloffset is in fact negative
12:01<@Alberth>oh, just use unary minus
12:02<@Alberth>or 0-x probably
12:02<Elyon>the building offsets are already allowed to be negative, but for some reason the `_validate_bounding_box` method expects pixeloffsets between 0 and 255, even though 128..255 are translated to -128..-1 by ottd
12:03<Elyon>if anything it seems like an oversight to me
12:03<@Alberth>sounds like a bug indeed
12:04<@planetmaker>Elyon, fix the bug while you're at hacking at NML ;)
12:04<Elyon>I'll modify the one line for it in a patch, seems a better solution than to work around a bug
12:04<frosch123>it's not that easy
12:04<frosch123>the childoffsets are not always signed
12:05<Elyon>when are they not?
12:05<frosch123>i think in newgrf context they are signed for objects/industries/..., but unsigned for stations :)
12:06<frosch123>traditionally offsets in ttd spritelayouts have been unsigned, since negative offsets do not work anyway
12:06<frosch123>newgrf made them signed, though negative offset still fail
12:06<frosch123>so the signedness depends on whether some ttdp guy decided to call a new function to fallback to an old one
12:07<Elyon>I used negative pixeloffsets just the other day
12:07<Elyon>we're talking childsprites here, right?
12:09<frosch123>hmm, wait, it's the other way around
12:09<Elyon>anyway, I had negative pixeloffsets working as intended in ottd the other day. Are you saying this might not be the case for ttdp?
12:10<frosch123>it's signed for stations in built-in layouts, and unsigned for the rest
12:10<Elyon>yeah, okay
12:10<frosch123> <- anyway, as i just wrote earlier, negative offsets glitch currently
12:10<frosch123>unless the pixels are transparent anyway
12:11<Elyon>huh, hmm ...
12:11-!-Haube [] has quit [Read error: Connection reset by peer]
12:11<Elyon>well, negative pixeloffsets are required for defining childsprites of station platforms in a meaningful way
12:11<frosch123>wrt. the signedness: DrawCommonTileSeq has a child_offset_is_unsigned parameter, which is used in hysterical consistent ways
12:12<Elyon>I ... think?
12:12<frosch123>wrt. the flickering: AddChildSpriteScreen skips the sprite, if the parent was clipped
12:13<frosch123>Elyon: currently you have to make parent sprites big enough by adding transparent pixels, so they include all their child sprites
12:13<Elyon>seems unwieldy
12:13<frosch123>but :) since i grew tired of explaining that to every newgrf author from scratch, it may be better to change ottd :)
12:14<Elyon>V453000: are you reading this?
12:14<frosch123>we had the same issue in yeti :)
12:14<frosch123>and ogfx, and ... :p
12:15<Elyon>so for now, station platform sprites should have padding-top of however much space we need for childsprites, and then childsprites should be positioned accordingly using 0 <= offset < 128?
12:15<frosch123>sometimes you just have to drop some ttd shenanigans :)
12:16<frosch123>Elyon: yes, something silly like that :)
12:16<Elyon>wow, okay. I hope you don't judge me too harshly for not figuring that out myself :p
12:16<Elyon>I'll leave the validator as it is, then
12:17<@Alberth>nml docs broken?
12:19<@Alberth>hmm, no of course, nml has no station support, silly me
12:19<frosch123> <- added it there
12:19<frosch123>no idea whether anyone needs offset >= 128
12:20<@Alberth>zoooooooom :)
12:22*Elyon is getting closer
12:23<Elyon>now we just need to set and check callbacks for differing spriteset/spritegroups
12:23-!-TheDude [~Thed@2a02:2b88:2:1::1d73:1] has joined #openttd
12:23<TheDude>hi planetmaker
12:26-!-Quatroking [] has joined #openttd
12:26<frosch123>any issue?
12:30-!-MTsPony [] has joined #openttd
12:30<TheDude>I wanted to make a planet :D
12:30<frosch123>you need to produce a lot of gas first
12:30<frosch123>but please not here
12:31<TheDude>nah I have an issue. I've got project at devzone and just setup translations. How do I do it if I want to edit base english file?
12:31<TheDude>of my project
12:31<frosch123>base language is edited via commits, not via the translator
12:31<TheDude>ok, and for any other language? Do I have to sign up for each individual language?
12:32<frosch123>usually people sign up for the languages they know :p
12:32<frosch123>if you have some other translation for your project, you can always commit translations, and eints picks them up
12:32<TheDude>but even as project manager I have to signup for the language?
12:32-!-smoke_fumus [~smoke_fum@] has joined #openttd
12:33<frosch123>if you want to use eints to upload other languages, you can assign yourself as "translation manager"
12:33<frosch123>then you can edit all languages in eints
12:33-!-FLHerne [] has joined #openttd
12:34<frosch123>but i would not know a reason to do that
12:35<frosch123>the idea is, that the developers work on the repository, and the translators via the translator
12:35<frosch123>eints picks up updates from the repository and commits changes from the translators
12:36<TheDude>but I still had to sign up as translator for my native language
12:36<frosch123>yes, but you became translator for many projects in that case
12:37<TheDude>I don't see my username in the menu where you pick the roles
12:37<TheDude>yy, that's good.
12:37<frosch123>you already have a role
12:37<frosch123>click your user on the left and click edit or something
12:37<TheDude>I am just curious about the traslation system
12:38<TheDude>oh, I see. Thanks
12:48<Elyon>`grep -Rn 'HACK:' nml` => :( :(
12:49<Elyon>anyway station spritelayout sprite properties support arrays of 2 expressions now
12:59-!-glx [] has joined #openttd
12:59-!-mode/#openttd [+v glx] by ChanServ
13:00-!-y2000rtc [] has joined #openttd
13:01<y2000rtc>Hi all. Can I have one question for you? pls
13:01<frosch123>what's the surface area of the moon?
13:02<y2000rtc>nono :)
13:02<y2000rtc>I would like to now how can I change the design of rail? I would like to have old design (in game deisgn for slow rail) for all rails.
13:04<frosch123>ideally you find the source of the newgrf you are using currently
13:04<frosch123>and just alter the speed properties in it
13:04<y2000rtc>Several types of rail is thing of newgrf file?
13:04-!-tedjam [] has joined #openttd
13:05<frosch123>default ottd only has plain rail, electrified, monorail and maglev
13:05<frosch123>neither of which have a speed limit
13:05<frosch123>anything "slow" is from a newgrf
13:06<y2000rtc>Ok, I will try to find which is the right file. And after this I have to change number of PCX file.
13:07-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
13:07<y2000rtc>I found it, Nutracks. It was quick. : o )
13:07<Elyon>frosch123: should we use cb14/var10 all the time, or introduce a simpler case for spriteset_num <= 1
13:07<frosch123>y2000rtc: <- nutracks source is here
13:08-!-tedjam [] has quit []
13:08<frosch123>Elyon: var10 is always used, but ofc you can skip the test if you have only one choice
13:10<Elyon>should we, though?
13:11<Elyon>it'll increase nml complexity while saving a bit of grf complexity
13:11<y2000rtc>It looks very complicated. : o )
13:11<frosch123>well, then don't do it, one can always add things later :)
13:12<y2000rtc>Maybe will be better to edit nfo file and again compile grf.
13:12<frosch123>if you think that would be easier :p
13:13-!-pxr [] has joined #openttd
13:14<y2000rtc>I checked nfo file and is not easier. : o ) Ok next night with editing.
13:17<y2000rtc>Which file from folder do I have to modify? It will be perfect information for me for start with searching.
13:23<@Alberth>but it's so much more fun when you add a few files
13:24<@Alberth>(and no, it's not likely that anyone here knows which file you need to change, we only know the path to the root of the repository, which you already have)
13:24<@Alberth>If I had to find it, I would also have to look through all files
13:28<Eddi|zuHause><frosch123> you need to produce a lot of gas first <- and then compress that gas into a star, make heavier elements, go supernova, form dust clouds, form a new star from the remaining gas, collide dust particles to form a larger dust ball, ...
13:29<Eddi|zuHause>i'm sure i forgot a few steps :p
13:31-!-tycoondemon [] has quit []
13:35-!-APTX_ [] has joined #openttd
13:36-!-tycoondemon [] has joined #openttd
13:37-!-Pensacola [] has quit [Remote host closed the connection]
13:40-!-Wolf01 [] has joined #openttd
13:41<Wolf01>hi o/
13:43-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Ping timeout: 480 seconds]
13:43<Wolf01>mmh, I just purchased the "new 3DS ambassador edition", I wonder if I could resell it :P
13:44<y2000rtc>I tried to cantct someone from team for creating of Nutracks. I will see.
13:45<frosch123>Wolf01: is it that crappy?
13:45<Wolf01>no, I'm wondering if it's bound to my account and if not how much to ask :P
13:47<frosch123>ah, somewhen nintendo things were region locked at least
13:47<frosch123>but those things change randomly all the time :)
13:47<Wolf01>I think it's still region locked, but nintendo had plans to remove it
13:48<Wolf01>I don't remember if directly on the "new 3DS" or with an update to the old 3DS too
13:54-!-Biolunar_ [] has quit [Quit: yo.]
14:02-!-andythenorth [] has joined #openttd
14:03-!-Haube [] has joined #openttd
14:05-!-naliao [] has joined #openttd
14:19-!-Myhorta [] has joined #openttd
14:39-!-luaduck is now known as luaduck_zzz
14:50-!-Myhorta [] has quit [Read error: Connection reset by peer]
14:52-!-FLHerne [] has quit [Remote host closed the connection]
14:52-!-FLHerne [] has joined #openttd
14:52-!-y2000rtc [] has left #openttd []
14:59-!-gelignite [] has quit [Quit:]
15:03-!-Suicyder [~Suicyder@] has joined #openttd
15:15<andythenorth>what hap?
15:18<frosch123>we ran out of anticipated station bear traps
15:18<frosch123>now we need to actually fall into them
15:19-!-sla_ro|master [slamaster@] has quit []
15:20<@Alberth>we also seem to be running low on problems in busy bee :p
15:22<andythenorth>problems to play, or problems to fix?
15:23<@Alberth>fix, I think
15:23<andythenorth>release it? :)
15:23<@Alberth>fine by me :)
15:23<@Alberth>no idea how to do that though :)
15:23<frosch123>what does it do?
15:24<@Alberth>gives you goals to achieve
15:24<andythenorth>don’t we just stick it on bananaramas?
15:24<@Alberth>deliver 50 tonnes coals to power plant
15:24<@Alberth>or 6,400 mail to blabla city
15:24<andythenorth>probably needs LICENSE.txt
15:24<@Alberth>~5 goals at a time
15:25<andythenorth>release it, say it’s a proof of concept
15:25<@Alberth>reach one, and you get a new one
15:25<frosch123>Alberth: i would advertise the "make bananas" method from silicon valley :p
15:25<@Alberth>sounds good
15:25<@Alberth>andythenorth: I added licenses to the code files recently
15:26<@Alberth>may also need a readme, I guess
15:26<andythenorth>call it v0.1
15:26<andythenorth>no readme :P
15:26<@Alberth>readme: tbd :p
15:27<@Alberth>:O we don't have a Makefile yet :p
15:28<andythenorth>copy one from frosch123 ? :P
15:28<frosch123> <- not much to do for scripts
15:28<@Alberth>good plan :)
15:28<frosch123>"bundle" and "bananas" are the only targets
15:28<frosch123>oh, and "clean"
15:28<frosch123>i copied it from pm, and deleted all i did not need
15:29<frosch123>hence all the weird _E and _V :p
15:29<@Alberth>yeah, I wondered whether we'd need them :p
15:31<andythenorth>hmm forums fund raiser isn’t done yet
15:31<andythenorth>seems slow
15:32<frosch123>it took a half year somewhen
15:32*andythenorth must be patient
15:33-!-FLHerne_ [] has joined #openttd
15:36-!-Pereba [~UserNick@] has joined #openttd
15:37<frosch123>Alberth: btw. i heard eints is a great tool to translate gs :p
15:38<frosch123>STR_LAKE_NEWS :There are {NUM} {}fish here <- what are the fish for though?
15:38<@Alberth>oh, is it? :)
15:38<andythenorth>oh that popped up some fishing news every 500 ticks or so
15:38<andythenorth>random news
15:38<@Alberth>andy stuff :)
15:39<@Alberth>add news for achieved goal?
15:39<@Alberth>or failed ones :p
15:39<frosch123>count score in fish?
15:39<andythenorth>earn fish
15:39<andythenorth>like those stupid badges in casual games
15:39-!-FLHerne [] has quit [Ping timeout: 480 seconds]
15:39<andythenorth>most pointless reward mechanic :P
15:39<@Alberth>no, honey, of course
15:39<@Alberth>or bees
15:40<andythenorth>bees buzz
15:45-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
15:48-!-Myhorta [] has joined #openttd
15:54-!-Quatroking [] has quit [Read error: Connection reset by peer]
15:59-!-gelignite [] has joined #openttd
16:00-!-Myhorta[1] [] has joined #openttd
16:05<Elyon>nml icon:
16:06-!-Myhorta [] has quit [Ping timeout: 480 seconds]
16:11-!-FLHerne__ [] has joined #openttd
16:12-!-FLHerne__ is now known as FLHerne
16:14-!-zeknurn [] has quit [Remote host closed the connection]
16:15-!-FLHerne_ [] has quit [Ping timeout: 480 seconds]
16:15-!-zeknurn [] has joined #openttd
16:39-!-Yotson [~Yotson@2001:980:6ac8:1:c897:194e:d5be:e9c4] has quit [Quit: .]
16:42<@planetmaker>Elyon, why a tooth as nml icon?
16:44<@planetmaker>still don't get it :)
16:45<@planetmaker>seems wiki helps
16:45<Taede>enamel sounds similar to nml, its the hard stuff on your teeth
16:45<@planetmaker>as such it makes sense :)
16:47-!-supermop [] has joined #openttd
16:48<Elyon>nml pronounced as a single word would be homophonal (??) with enamel, well almost
16:49-!-Suicyder [~Suicyder@] has quit [Quit: HydraIRC -> <- s0 d4Mn l33t |t'z 5c4rY!]
16:50<@planetmaker>I like the idea :)
16:50<Elyon>it was mostly a joke :p
16:50<Elyon>I doubt nml needs an icon anyway
16:51-!-zeknurn` [] has joined #openttd
16:51<@planetmaker>it doesn't need one. But could have one ;)
16:57-!-zeknurn [] has quit [Ping timeout: 480 seconds]
17:03-!-Biolunar [] has joined #openttd
17:06-!-Progman [] has joined #openttd
17:09-!-andythenorth [] has left #openttd []
17:26-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
17:28-!-HerzogDeXtEr1 [] has quit [Quit: Leaving.]
17:30-!-gelignite [] has quit [Quit:]
18:01-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
18:13-!-oskari89 [] has quit []
18:15-!-naliao [] has quit [Read error: Connection reset by peer]
18:18-!-Progman [] has quit [Remote host closed the connection]
18:21-!-FLHerne [] has quit [Quit: There's a real world out here!]
18:47-!-dreck [] has joined #openttd
18:48<dreck>how long did this long drone about grf properties go on for? heh I had to leave as it was getting a bit too boring for me reading through the long wall :->
18:48<dreck>(no offence ofc)
18:49<Elyon>:D none taken
18:49<Elyon>well we stopped a few hours back
18:50<dreck>heh ok
18:50<Elyon>some hours back, probably 6-8 hours
18:50<dreck>actually...thats a good question..where did the expression "a brick wall of text" really come from....
18:50*dreck wonders if theres an answer online
18:50<Elyon>the nml station specs are getting fleshed out
18:50<Elyon>it's just a wall of text, not a brick wall
18:50<Elyon>brick walls are for head-running-against
18:52<dreck>"to relieve stress bang your head on the red circle" aka target circle taped to a hard wall
18:52<dreck>silly thing that one..I've actually see a few of these kind in person
18:53<dreck>stress != physical headache heh
18:53<dreck>anyway elyon what're you doing atm?
18:54<Elyon>programming with visitor
18:54<dreck>ah ok
18:54<dreck>what language?
19:02<dreck>sounds like fun :)
19:05-!-supermop [] has quit [Ping timeout: 480 seconds]
19:18<frosch123>TheDude: i think english.txt is missing a "##plural 0", that's why eints lists 6 invalid strings
19:20-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
19:38-!-Myhorta[1] [] has quit [Read error: Connection reset by peer]
20:08-!-dreck [] has left #openttd []
22:02-!-Flygon_ [] has joined #openttd
22:05-!-Flygon__ [] has joined #openttd
22:08-!-glx [] has quit [Quit: Bye]
22:08-!-Flygon [] has quit [Ping timeout: 480 seconds]
22:10-!-Flygon_ [] has quit [Ping timeout: 480 seconds]
22:26-!-Flygon_ [] has joined #openttd
22:28-!-Flygon__ [] has quit [Ping timeout: 480 seconds]
22:37-!-Flygon [] has joined #openttd
22:43-!-Flygon_ [] has quit [Ping timeout: 480 seconds]
22:48-!-supermop [] has joined #openttd
22:54-!-Biolunar_ [] has joined #openttd
23:01-!-Biolunar [] has quit [Ping timeout: 480 seconds]
23:16-!-DDR [] has joined #openttd
23:24-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Read error: Connection reset by peer]
23:28-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has joined #openttd
23:32-!-Pereba [~UserNick@] has quit [Quit: This is AdiIRC!]
23:40-!-itsatacoshop247_ [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has joined #openttd
23:44-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has quit [Ping timeout: 480 seconds]
23:49-!-quorzom [] has quit [Read error: Connection reset by peer]
23:59-!-itsatacoshop247_ [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has quit [Ping timeout: 480 seconds]
---Logclosed Fri Jan 09 00:00:19 2015