IRC logs for #openttd on OFTC at 2015-01-08
⏴ go to previous day
00:00:23 <Elyon> no, I've been using advspritelayouts exclusive
00:00:40 <Elyon> I've never tried any other layouting than your advspritelayouts :D
00:00:47 <Elyon> I have no idea how they work
00:01:08 <frosch123> anyway, what's "loaded_threshold"?
00:01:20 *** BiG_FISHBOT is now known as Hazzard
00:01:23 <Elyon> and tbh shouldn't NML just always use advspritelayout?
00:01:36 <Elyon> should I call it lots_threshold instead? You mentioned vehicles call it loading/loaded
00:01:37 <frosch123> looks fine to me, though i am sure there will be more bear-traps :)
00:01:50 <Elyon> bear-traps inbound indeed
00:02:08 <frosch123> lots/little and loaded/loading are different things
00:02:17 <Elyon> the first one was to leverage Action2Layout objects without generating action2s
00:02:27 <frosch123> sure, you can use the same name for the first version
00:02:27 * Elyon renames to lots_threshold
00:02:35 <frosch123> but it would be hard to explain to a new guy :p
00:02:52 <Elyon> lots_threshold is probably better then
00:03:10 <Elyon> API changes are not a favourite pastime of mine
00:03:49 <Elyon> well they are, but I get ill-mannered comments about them
00:04:06 *** Hazzard is now known as BiG_FISHBOT
00:04:06 *** Hazzard has joined #openttd
00:09:23 *** Hazzard is now known as BiG_FISHBOT
00:09:53 * Elyon renamed `station_class` to `class` and introduced `classname`, to be consistent with Object properties
00:09:57 *** BiG_FISHBOT is now known as Hazzard
00:16:28 *** Hazzard is now known as HazzardServer
00:17:02 *** HazzardServer is now known as Hazzard
00:21:50 <Elyon> alright, I should at the very least have that example syntax working tomorrow
00:49:36 <frosch123> i changed some details in the grf generation, which should make it easier, while not adding restrictions
00:50:05 <frosch123> but, i think we still have some issue with different x/y offsets for orientations
00:55:10 <frosch123> hmm, the older examples in that task do not address the orientation issue at all :/
00:55:43 <frosch123> so, i guess this new syntax is at least better than the older ones :p
01:01:59 <Elyon> frosch123: okay this is good
01:02:48 <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?
01:03:30 <frosch123> flipping makes no sense for childsprites
01:03:39 <frosch123> so, i very much doubt ottd does anything there
01:03:50 <Elyon> well, if it doesn't, what should we do?
01:04:01 <frosch123> the default layouts in table/station_land.h also do manual flipping
01:04:30 <frosch123> i think nml generating the two layouts from one spritelayout is still the right thing
01:04:41 <frosch123> but it may need more than the orientation_offset for the sprite
01:05:40 <frosch123> if everything fails, one could allow lists with two items [x value, y value]
01:05:49 <Elyon> well, CATS should use a lot of the advspritelayout features, and I'm developing that while developing nml stations
01:06:11 <Elyon> then one might as well just have two spritelayouts and a layoutgroup
01:06:35 <frosch123> actually, thinking about it... for the position offsets those values are either constant, or if dynamic then completely different
01:06:49 <frosch123> hmm, so i guess it should be done as for house properties
01:07:07 <frosch123> various house properties allow a single value to make it the same for all tiles of a house
01:07:16 <frosch123> or a array [ ] with a fixed amount of items
01:07:24 <frosch123> that may be the right thing for the offsets
01:08:03 <Elyon> also, "Each station spritelayout creates two action0 items" ?
01:08:37 <Elyon> yes, that makes more sense :D
01:09:16 <Elyon> first I have to stop `spritelayout()` from generating an action2 though
01:11:35 <Elyon> in fact, I have to catch spritelayout in the act of generating action2s and have it generate action0properties instead
01:12:26 <frosch123> well, they are not generated immediately, but rather collected, and dumped at the end
01:12:49 <Elyon> hmm, yes, I will have to read quite a bit of the source to understand how it does that, I think
01:13:09 <frosch123> similar as to sounds
01:13:20 <frosch123> action2 can freely reference sounds
01:13:29 <frosch123> and at the end they are dumped into a single action11
01:13:50 <Elyon> ah, I will try to mimic that procedure, then
01:15:05 <Elyon> except I need to intercept the station action0
01:15:26 <frosch123> not sure it needs to be in the same action0
01:15:44 <frosch123> but you somehow need to know the id of the first valid station :p
01:15:54 <frosch123> but, i guess just assume 0 for now
01:16:20 <frosch123> anyway, not sure what timezone you are in, but i am going to sleep :)
02:13:03 *** Buntunub has joined #openttd
02:29:33 *** supermop has joined #openttd
03:26:58 *** luaduck_zzz is now known as luaduck
03:55:16 *** Biolunar_ has joined #openttd
04:27:26 <Elyon> action2layouts collected, injected into action0s
05:07:48 *** supermop has joined #openttd
05:53:15 *** Pereba_ has joined #openttd
05:55:20 *** Pereba_ is now known as Pereba
05:56:16 *** Eddi|zuHause has joined #openttd
06:08:16 *** Pereba_ has joined #openttd
06:10:22 *** Pereba_ is now known as Pereba
06:37:27 *** HerzogDeXtEr1 has joined #openttd
06:42:57 <Elyon> nml/actions/action2layout.py:442: #no sprites defined at all, that's not very much.
08:18:12 <^Spike^> for the ppl who want to know: nml is added @ paste of ottdc (Thnx to Sylf)
09:01:26 <Eddi|zuHause> what on earth is a kix test?
09:15:26 *** supermop has joined #openttd
09:20:26 <Supercheese> If you had never heard of Kix cereal or its annoying commercial, the comic would make little sense
09:20:52 <Supercheese> commercial slogan*
09:21:14 <planetmaker> it's not exactly a word which one is exposed to, if not living in an English-speaking country
09:21:25 <planetmaker> emphasis on living
09:21:49 <peter1138> planetmaker, it's a US thing. I have no idea, and I live in an English-speaking country.
09:21:54 <Supercheese> they spammed their television commercials like crazy for a few years here
09:22:02 <planetmaker> k, then make it even narrower :)
09:59:56 *** petern_ has joined #openttd
10:03:35 <petern_> Damn at ^U not working
10:18:57 <planetmaker> landscape smells when inhabited by mamals
10:20:45 <planetmaker> I don't understand your problem with landscape, V453000 :) It's 100% dead easy. Just sprite replacement, nothing else
10:20:54 <planetmaker> Except shores and rivers :P
10:29:52 *** itsatacoshop247 has quit IRC
10:40:51 <dihedral> V453000: make code some flow fileds - code different flowers on different hill slopes, i.e. slopes facing NE or SW ...
10:41:38 <peter1138> Don't forget about fileds.
11:10:17 * planetmaker prefers filets ;)
11:10:31 <V453000> I know I already got it all written down and prepared
11:10:38 <V453000> but it is a lot of stuff simply :D
11:10:57 <V453000> also WTF at the 4 rough flat tiles
11:12:43 <V453000> even shores and rivers make more sense than that :D
11:13:26 <planetmaker> it's simply more variety
11:14:22 <V453000> well sure that is absolutely awesome, but systematically among the sets of 18-differently-orientated-tiles it is quite a wtf
11:15:43 <dihedral> who needs variaty? make all landscape tiles black!
11:15:51 <dihedral> then you need not rotat anything either
11:16:44 <V453000> XD valid point but it is nice to see where is a hill and where is not :P gameplay raizins
11:18:59 <supermop> Supercheese: Kix had that slogan when my mom was a kid
11:20:20 <dihedral> V453000: you would see when you start building :-P or look at the minimap
11:35:28 *** Klanticus has joined #openttd
12:07:10 *** sla_ro|master has joined #openttd
12:09:19 *** frosch123 has joined #openttd
12:25:46 * dreck pokes ngc with a map pointing to the real switzerland
12:26:08 <NGC3982> Let's fix that, actually.
12:26:35 <NGC3982> I haven't really put any effort in NewGRF-to-map realism on the servers yet.
12:27:00 <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 :)
12:27:51 <NGC3982> Oh, you didn't want to play with me? :P
12:27:58 <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
12:28:04 <dreck> ngc..no not you, just in general
12:28:37 <NGC3982> Aight. Well, i found it in the favourite-GRF thread on /r/openttd on Reddit.
12:29:09 <NGC3982> The NewGRF name "SBB set v1.0b" doesn't really advertise a fantastic train NewGRF. :-)
12:29:59 <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 :)
12:30:44 <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
12:31:06 <dreck> ngc..the big locomotive with flexible nose ends? its the one rated for 66kph with heavy trains early on
12:32:20 *** Supercheese is now known as Guest1134
12:32:23 <Elyon> frosch123: when the action 3,2 chain doesn't end in a sprite group, should I generate a spritegroup or an action2real?
12:32:25 *** Supercheese has joined #openttd
12:32:38 <frosch123> what? you are awake again?
12:33:44 <NGC3982> dreck: Oh! I like that.
12:33:49 <Elyon> 0.005 kibihours of sleep ought to be enough for everyone
12:34:24 <frosch123> Action2Real is a class in nml.actions, what is spritegroup?
12:34:47 <frosch123> there is nothing like that in nml.actions
12:35:27 <Elyon> no, a spritegroup is just a special action2?
12:36:53 <frosch123> i think you need to use create_spriteset_actions()
12:37:03 <Elyon> the option is either to generate a spritegroup when a spriteset is referenced, or to allow FEAT_STATIONS items to reference spritesets directly
12:37:09 <frosch123> it takes a ASTSpriteGroup and returns a action
12:37:32 <Elyon> well feature 0x04 doesn't "support" spriteset actions by default, though it's an eeeasy addition
12:37:40 <frosch123> referencing spritesets in the item makes no sense?
12:38:00 <Elyon> it's just a shorthand for a spritegroup with 1 entry?
12:38:07 <frosch123> i think i don't understand you :p
12:40:12 <Elyon> hmm ... should nml station item switch chains always end in explicit spritegroups?
12:40:55 <frosch123> for the graphics items: yes
12:41:22 <Elyon> that seems unwieldy in the case where the station does not change its graphics based on little/lots
12:41:23 <frosch123> though yesterday we considered a short-hand for referencing a spriteset, which would generate a one-item spritegroup in-between
12:41:36 <Elyon> some things already provide this shorthand I believe?
12:42:22 <frosch123> i think vehicles always have to use a spritegroup
12:42:32 <frosch123> other features do not have such a hing
12:43:42 <Elyon> frosch123: ah, hmm, err
12:44:09 <Elyon> frosch123: how do you explain the `action2.create_spriteset_actions` function then? :p
12:44:24 <dreck> anyway what're you doing atm ngc? :)
12:44:40 <Elyon> and specifically, it's description: "Create action2s for directly-referenced sprite sets"
12:44:58 <V453000> excellent, 4864 x 29440 px sprite sheet
12:45:15 <Elyon> you will soon hit gigapixels
12:45:26 <V453000> more like holyshitpixels
12:46:05 <V453000> actually I could put more in there, yeah
12:46:49 <frosch123> Elyon: huh? there is create_spriteset_actions for vehicles, and there is make_simple_real_action2 for cargos (i believe)
12:47:06 <frosch123> stations have to use create_spriteset_actions, because that is what newstations expects
12:47:34 <Elyon> frosch123: hmm ... yes. and that takes a spritegroup
12:48:13 <frosch123> create_spriteset_actions otoh is just some loop, which calls make_simple_real_action2 again
12:48:43 <frosch123> so, you can still invent some dummy-spritegroup when referening only one spriteset
12:49:00 <Elyon> yeah ... but, for example, objects support referencing layouts instead of spritegroups
12:49:18 <frosch123> yes, but objects do not use action2real
12:49:47 <Elyon> yes, I'm just thinking about the nml syntax here, not the actual implementation
12:50:25 <frosch123> well, in that case spritelayouts of stations should be allowed to both reference single spritesets and spritegroups
12:50:34 <frosch123> where spritegroups is the normal case for little/lots
12:50:44 <frosch123> and spriteset is a shorthand for ignoring little/lots
12:50:56 <frosch123> which implicitly generates an intermediate spritegroup
12:51:05 <Elyon> yeah, I had it all tangled up
12:51:32 <Elyon> item(FEAT_STATIONS) graphics must end in a spritelayout, yes?
12:51:58 <Elyon> and each spritelayout generates corresponding action2s to the referenced spritesets and spritegroups
12:52:18 <Elyon> where if there are referenced spritesets, dumb spritegroups are just generated?
12:52:23 <frosch123> yes, plus the callback for the action0 spritelayout index
12:53:07 <Elyon> but it will eventually end in a spritegroup/"spriteset-as-group"
12:53:33 <Elyon> depending on cb14 it'll be the relevant spritegroup
12:54:59 <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/?
12:55:22 <frosch123> yes, 0A works for 1A
12:55:40 <frosch123> i think using the same layouts for all stations makes the implementation easier
12:55:53 <Elyon> less neat output, though
12:55:53 <frosch123> there is no real limit on the amount of layouts (32k i believe)
12:56:13 <frosch123> and you do not run into issues with nml-switches being shared between stations
12:56:45 <frosch123> but, sure, if you can deal with shared switches, and generate matching layouts :) sure it would be better :)
12:56:45 <Elyon> so let's say switch3->switch2->switch1->spritelayout
12:57:01 <Elyon> but switch2 branches differently depending on the station?
12:57:14 <frosch123> no, two items reference switch2
12:57:49 <frosch123> so if you have spirtelayout1, ... spritelayout5: one item may use layout1 to 3, and another item may use layout2,4,5
12:58:06 <Elyon> [station0, station1] -> switch2 -> switch1 -> [layout0, layout1, layout2, layout3]
12:58:20 <Elyon> this still means all four layouts are relevant for stations 0 and 1
12:58:43 <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
12:58:44 <Elyon> so station0 gets prop1A, station1 gets prop0A unless it has more layouts that station0 doesn't have?
12:59:25 <frosch123> ah, true, there is also an intermediate solution :) only share spritelayouts accross items which share some layout
12:59:27 <Elyon> or allocate a register per station
13:00:01 <Elyon> frosch123: ah, hmm, yes ... virtual layoutgroups, of sorts?
13:00:38 <frosch123> however, while this is some detail: a grf developer can also disable a item by wrapping it inside a "if"
13:00:46 *** Suicyder has joined #openttd
13:00:47 <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
13:01:01 <frosch123> in that case this station cannot be used for the original spritelayout definition
13:01:07 <frosch123> but meh, i would ignore that for now
13:01:28 <Elyon> or we could just set 1A property for every station :D worst of both worlds
13:01:37 <Elyon> *set 1A prop identically
13:01:48 <frosch123> well, it would still be un-noticable in a 32bpp zi4 set :p
13:02:09 <Elyon> ? what do you mean unnoticable?
13:02:47 <frosch123> what do a few kilobyte more matter to a 150MiB grf?
13:03:31 <Elyon> I am more worried about how ottd handles, say, 5,000 layouts in prop1A
13:04:00 <frosch123> they are copied more or less unmodified onto the heap
13:04:01 <Elyon> whether it truly is a `switch` statement in the ottd source; a loop would have a noticeable impact I would think
13:04:13 <frosch123> while property 1A may actually share the pointers
13:04:55 <frosch123> hah, not even that, 0A copies the data, nothing is shared
13:05:03 <Elyon> ah, I guess if it's just `layout = layoutpointers[index]` then that should be fine
13:05:11 <frosch123> so, duplicating 1A or using 0A makes no difference for ottd
13:05:35 <Elyon> haha, okay. Well, using 0A is neater, 1A is easier
13:06:05 *** LadyHawk has joined #openttd
13:07:26 <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]
13:07:45 <Elyon> and then some conditionals/tempvars to handle iffed-out layouts
13:08:11 <Elyon> ORRR just set prop[1A] for every station and that magically makes iffing-out station items work
13:08:47 <Elyon> slightly/quite bigger GRF though
13:09:13 <Elyon> but I see the appeal of having every layout available to every station so we don't need to mess with cb14 offsets
13:09:36 <Elyon> every virtual layoutgroup, that is
13:12:47 <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
13:13:19 <frosch123> well, i do not expect that much variety in layouts :p
13:13:34 <frosch123> so, if grfs end up with lots of layouts, i would rather look into detecting duplicates
13:13:35 <Elyon> I might leverage the fact that I can have 16384 layouts
13:13:50 <frosch123> why would you have different layouts?
13:14:02 <frosch123> using different spritesets in a layout do not change it
13:14:24 <frosch123> and using different positions is very unlikely i think
13:14:50 <Elyon> I could have the intended CATS layout variation in prop1A instead of in action2random?
13:15:00 <frosch123> i think when using a offset register for the sprite, every stationgrf should get away with less than 20 layouts
13:15:11 <Elyon> yes, that's what I have been doing until now
13:15:30 <frosch123> anyway, no need to deal with that unless it becomes an issue :)
13:16:08 <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
13:17:10 <Elyon> so, in the end - "all prop1A" or "just one prop1A and the rest prop0A"?
13:17:17 <frosch123> yes, that is one offset to the spriteset
13:17:20 <frosch123> but the same layout in all cases
13:18:52 <Elyon> cargosprite is dependent on a number of things, but some of those things could be in layouts as well
13:19:20 <Elyon> for example, each cargotype has 8 variations which each have 4 sizes
13:20:06 <Elyon> selecting the variation combinations of the 8 (or even 16) cargospaces on the station tile can be done at compile-time with prop1A
13:20:13 <frosch123> different sprites for cargos, selected via a register
13:20:17 <frosch123> but it only needs one layout
13:22:01 <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
13:22:38 <Elyon> and /these/ action2var would each become more complex if they need to both determine the size and set the cargovariant
13:22:58 <frosch123> no idea what you try to achieve, but randomaction is not the only method to do random
13:23:16 <frosch123> you can access the random bits as variable "random_bits" and directly use it in computations
13:23:47 <frosch123> sprite: front_sprites(2 * (LOAD_TEMP(0) + (random_bits >> LOAD_TEMP(1)) & 0x3));
13:23:58 <frosch123> select cargo via register 0
13:24:05 <frosch123> four variations per cargo type
13:24:15 <frosch123> selected via random bits selected by register 1
13:24:15 <Elyon> no, 32 variations per cargo type
13:24:27 <frosch123> well, "& 1F" then :)
13:24:45 <Elyon> 8 completely random variations, each with 4 completely cargoamount-specific sizes
13:25:55 <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
13:26:21 <Elyon> I don't know, `compile-time` is a plusword in my book
13:27:00 <Elyon> this is an oddly specific use case though
13:28:07 <Elyon> of course, all this can be achieved with just /one/ spritelayout and a few somewhat more complex action2var expressions
13:28:37 <Elyon> I just figure indexing into spritelayouts is faster than a randomly-based branch
13:28:59 <Elyon> especially for large amounts of layouts vs large amounts of random-branches
13:30:01 <Elyon> oh, right, I didn't need that random-branch as I can access the randombits directly in an action2var
13:30:41 <Elyon> which also removes the virtual limit of 256layouts for a single var2random
13:31:15 <Elyon> at the expense of becoming more runtime than compiletime resolving of graphics
13:31:23 <frosch123> as said, you do not need var2random
13:31:36 <frosch123> you can use random_bits in a regular switch
13:31:41 <frosch123> or inside computations
13:31:59 <Elyon> but that's more runtime computations
13:32:04 <frosch123> i consider "var2random2" a deprecated thing, it's only needed for rerandomisation
13:32:20 <Elyon> I guess I shouldn't worry about performance until it becomes an issue
13:32:40 <Elyon> my previous question still stands, though;
13:33:18 <Elyon> "prop1A for the lot" => simpler implementation, automagic item if-skip handling
13:34:03 <Elyon> "prop1A for one and prop0A for the rest" => complex implementation, care must be taken to support if-skip
13:35:55 <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
13:39:14 <Elyon> each spritelayout can use 7 different spritegroups, but you can create an almost-arbitrary amount of spritelayouts, yes?
13:40:22 <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)
13:41:10 <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
13:42:11 <V453000> this chat is more wild than usual XD
13:42:50 <Elyon> I wanted the cats grfid as 0xCA57CA75
13:43:07 <Elyon> but that's high ascii so :(
13:45:38 <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
13:45:52 <V453000> XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
13:46:07 <V453000> we cant use that ID? :(
13:46:43 <planetmaker> Elyon, no problem with high ascii grfIDs
13:47:34 <Elyon> oh. Well in that case, how do I insert byte literals in stringliterals in nml(literals literals)
13:48:21 <Elyon> oh, lowercase hexdigits
13:48:49 <Elyon> haha, nml does not agree; value for prop8 must be of length 4
13:49:08 <Elyon> probably just a sanity check
13:49:26 <frosch123> Elyon: in addition, every spriteset can contain an almost-arbitrary amount of sprites
13:50:22 <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?
13:51:06 <frosch123> well, from a performance pov, less spritesets is better :p but, well, performancy is hard to predict
13:51:08 <Elyon> I guess implementing multi-spriteset inherently also implements single-spriteset
13:51:29 <frosch123> in any case, usually stations are not the performance bottle neck
13:51:32 <Elyon> and it shouldn't be too bad, really
13:51:49 <Elyon> V453000: we could be using two, though
13:51:50 <frosch123> stations hardly do anything if not visible
13:52:03 <frosch123> so, they do not scale with map size like other stuff
13:52:05 <Elyon> frosch123: stations will be the performance bottleneck once CATS is released
13:52:07 <planetmaker> does it work with "\CA\75\CA\75" ?
13:52:51 <planetmaker> I wonder then why firs works with grfid: "\F1%\00\05";
13:53:35 <Elyon> I've been setting station classid this whole time
13:54:27 <Elyon> although to be honest that should have been evident from "Value for /property 8/ must be of length 4"
13:54:53 <frosch123> planetmaker: is the "%" instead of "\25" a left-over from the nfo->nml conversion?
13:55:04 <frosch123> it does not look like a human would write it that silly
13:55:09 <Elyon> although interestingly grfid is set in /action 8/
13:55:09 <planetmaker> I've no clue really
13:55:53 <Elyon> \ca\75\00\00 could work as well
13:56:34 <planetmaker> Choose whatever you like really... and be aware that some people disagree with that :P
13:56:51 <V453000> I AGREE WITH EVERYTHING
13:57:15 <V453000> yeah we need to start the grf name with ca
13:57:17 <Elyon> and the award goes to V453000
13:57:51 <V453000> just to fill you in, there has been awesome drama/war over grf ID starting with CA previously XD
13:57:53 <Elyon> and then we can have 65536 distinct grfs in the CATS name
13:57:59 <V453000> CAnadian bullshit privilegez! :D
13:58:02 <Elyon> not that I think we ever need more than just CATS
13:58:14 <planetmaker> V453000, "CAXX" != "\CAXXX"
13:58:44 <Elyon> and you don't think they would lay claim to both "CA" and "\CA" prefix?
13:59:49 <Elyon> frosch123: I'll just set prop1A for every station for now
13:59:54 <planetmaker> Elyon, 256^3 grfIDs are not enough. So sure they would
14:00:25 <Elyon> CA prefix is only 256^2 IDs though
14:00:56 <Elyon> who cares, it's grfid anyway. It's supposed to be unique and that's it
14:04:36 <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
14:05:01 <Elyon> I'm hoping someday to have those of you with /real/ insight tear my patches apart :D
14:05:49 <Elyon> also, is the `"string %s interleaving" % format` python3 only, seeing as you haven't been using it in nml before?
14:06:17 <frosch123> no, that rather looks like python2
14:06:26 <frosch123> nml is python 3, which uses {} instead of %s
14:06:45 <Elyon> what's the benefit of {} over %?
14:06:52 <Elyon> I've been using % for ease-of-use
14:07:10 <frosch123> no idea, albert has more insight into pythoni
14:07:24 <SpComb> {} does slightly more things than % does
14:07:30 <frosch123> but %s looks like c, it specifies the type of the argument, though that is known anyway
14:07:58 <frosch123> {} makes it easier to group various formatting modifiers
14:08:11 <SpComb> it can also do attribute/index lookups
14:08:18 <Elyon> yet nml uses `{:d}` liberally :p
14:08:44 <Elyon> anyway, I'll be using {} then
14:09:58 <Elyon> and how do we feel about list/set comprehension?
14:10:05 <Elyon> I've been using them extensively so far
14:16:41 <frosch123> albert is a fan of them, so i believe him :)
14:17:12 <Elyon> makes it super concise to collect all station action0s, at least
14:17:16 <Elyon> or action3s for that matter
14:17:54 <Elyon> also, I went with injecting the 1A prop into the current action0 instead of creating a new action0. It seemed neater.
14:32:21 <Elyon> frosch123, I had a /crazy/ idea
14:32:37 <V453000> that sounds dangerous
14:32:38 <frosch123> coding a animal-named station grf?
14:33:10 <Elyon> you know how orientation_offset, orientation_xoffset, etc. gets unwieldy?
14:34:37 <Elyon> the properties of `flip` are property offsets for the flipped layout
14:35:08 <Elyon> so `flip { xoffset: -16; }` translates to `xoffset - 16`
14:36:23 <Elyon> although xoffset and yoffset are swapped automatically for building sprites
14:37:44 <Elyon> oh okay, that is even better then
14:37:51 <Elyon> consistency is key, etc.
14:38:16 <frosch123> also, i think that these offsets are either compile-time constant, or completely differently computed for orientations
14:38:30 <frosch123> so, when using [], it does not need to support variables
14:38:46 <frosch123> but could blame the user to evaluate direction
14:39:22 <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
14:39:31 <Elyon> hmm, so for each property of a sprite, [x, y] indicates the absolute value for orientation x and y, respectively?
14:39:50 <frosch123> yes, that works fine for the offsets
14:40:05 <frosch123> it does not work well for "sprite" and "palette" though :p
14:40:35 <frosch123> palette is unliekly to ever depend on orientation though
14:40:57 <frosch123> so, one could just stick to "orientation_offset" for "sprite", and use [] for all other items
14:42:16 <frosch123> hmm, that's an interesting option as well
14:42:22 <frosch123> particulary because of the spritegroups
14:42:40 <frosch123> adding a () parameter to spritegroup references looks weird, since the parameter does not select the spriteset
14:42:47 <frosch123> but is rather passed no to the spritesets
14:43:24 <frosch123> so, detaching the parameter entirely from the spriteset/spritegroup reference could be a nice solution
14:44:15 <Elyon> sprite: super_awesome_spritegroup; sprite_offset: [14, 15];
14:44:32 <Elyon> instead of sprite_offset I mean
14:45:56 <Elyon> `sprite_offset: [x, y]` is probably easier to make runtime-evaluatable as well
14:46:18 <Elyon> since it's just a pseudoproperty that sets sprite:
14:46:31 <planetmaker> what's that sprite offset?
14:46:49 <frosch123> it selects the sprite from the spriteset
14:47:38 <frosch123> that stuff works different to industries/objects because of the little/lots thingie
14:47:40 <Elyon> frosch123: since it is a property of a sprite, the "sprite_" prefix seems redundant
14:48:17 <frosch123> there is already xoffset, yoffset and zoffset, so "offset" may look weird
14:48:35 <frosch123> maybe we can find a completely different word, not using "offset" :)
14:48:53 <Elyon> it can be read as 'sprite.offset, sprite.xoffset, sprite.yoffset' etc.
14:49:10 <Elyon> in my opinion, `sprite.offset` is pretty clear
14:49:39 <Elyon> sprite: GROUNDSPRITE_TRACK; index: [0, -1]
14:49:55 <Elyon> makes more sense to call it index for spritegroups/spritesets though
14:49:56 <frosch123> it's only a name, time will tell what goes fluent
14:50:25 <Elyon> `orientation_dependant_sprite_index_offset`
14:52:44 <planetmaker> hm... undecided :)
14:54:58 <Elyon> pm: it's not just for spritesets though, as other Expressions are supported as well
15:17:43 <Elyon> so, support for every spritelayout sprite property as [x, y]?
15:22:06 <Elyon> (for stations only of course)
15:35:05 <Elyon> I wish nml would print stacktraces on internal errors
15:36:58 <frosch123> there is a "DEBUG" variable at the top of main.py
15:37:08 <frosch123> you need to set that one
15:37:25 <frosch123> developmode = False # Give 'nice' error message instead of a stack dump. <- that one
15:37:43 <frosch123> though there is also a command line option to enable it
15:44:05 <frosch123> i also only found it somewhen :)
15:45:18 <Elyon> oooh, --debug prints the AST (which I just now figured maybe stands for abstract syntax tree?)
15:45:27 <Elyon> no more compiling to NFO and checking the results myself
15:45:52 <Elyon> wait, the AST is just ... nevermind
15:50:02 <Eddi|zuHause> there is the -s switch if you want stacktraces
15:53:24 <planetmaker> helau for nmlc --help :P
15:54:08 <frosch123> planetmaker: that does not help, once you tried "--debug", it's to scary to try the rest
15:54:53 <Elyon> I did find it through --help though
15:55:03 <Elyon> | grep debug was a red herring
15:57:08 <frosch123> i feel like there was more here or on the forums, but i did not find particulary much
15:58:25 *** Alberth has joined #openttd
15:58:25 *** ChanServ sets mode: +o Alberth
16:01:43 <Rubidium> maybe something about the bit 8 for articulated vehicles?
16:02:33 <Rubidium> wasn't there something that you can only use vehicle id 0..127 for articulated vehicles?
16:02:53 <frosch123> haha, we extended that in version 8 already :p
16:04:53 <planetmaker> :) 8k (or 16k?) articulated vehicles right now
16:06:11 <planetmaker> frosch123, what about views for vehicles instead of subtypes?
16:06:40 <Eddi|zuHause> i think it's 16k
16:06:40 <frosch123> there is a separate unwritten page about that :p
16:06:41 <planetmaker> they would have the explicit limitation that nothing can query it
16:06:52 <Eddi|zuHause> but i' not sure anymore
16:07:07 <Alberth> assume 8k, it can only get better :)
16:07:15 <Eddi|zuHause> should be 14 bits plus one "reverse" bit
16:07:44 <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 :)
16:08:07 <Eddi|zuHause> planetmaker: i don't think views need "can't be queried", just "can't be changed after purchase"
16:08:08 <frosch123> it's not really a incompatible change
16:09:37 <Eddi|zuHause> frosch123: well, if it's tied to a GRF version, then you can know when to omit all the purchase list branching
16:09:43 <planetmaker> but it would be incompatible to drop the subtypes :P
16:10:01 *** gelignite has joined #openttd
16:10:25 <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
16:10:49 <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]` ?
16:11:03 <Elyon> it's the easiest way to implement sprite-property-as-array, but it seems a bit hack-ish
16:12:00 <Alberth> I don't know what you ask in terms of NewGRF, but in terms of Python, "isinstance" is considered bad style
16:12:11 <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
16:12:12 <Eddi|zuHause> Elyon: have you looked at other lists, like cargo refitting?
16:12:35 <Elyon> Alberth, well NML is littered with isinstance so I figured it was the go-to check
16:12:38 <frosch123> houses have several properties in the item, that can be set as array,or as single value
16:13:03 <Elyon> frosch123, Eddi, I didn't even consider that. How terribly ignorant of me, my apologies. Thanks!
16:13:35 <Alberth> Elyon: yes, it is :( It was written by someone learning Python :)
16:14:03 <Elyon> so a try/catch or what?
16:14:39 <Elyon> what is the pythonic way of conditional branching by object class?
16:15:30 <Elyon> if hasattr(attr_to_look_for) ?
16:16:59 <Eddi|zuHause> basically, yes. you would want to check whether the object "implements a protocol"
16:17:39 <Elyon> I've noted that as TODO, now
16:18:41 <Alberth> in general, you should know what properties the thing you have can do, and use it as such
16:19:16 <Alberth> that makes it possible to give you any object I want, as long as I provide the capabilities that you need/assume
16:19:36 <Alberth> if you do explicit object-type testing, such code will fail
16:19:56 <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
16:20:19 <Elyon> Alberth: that makes much-a sense-a
16:20:23 <Eddi|zuHause> for my taste, python lacks a few builtins to check for protocol compliance
16:20:47 <frosch123> Elyon: houses look like they convert single values to arrays in all cases
16:21:07 <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
16:21:13 <frosch123> there is 'multitile_function
16:21:28 <frosch123> there is 'multitile_function', which is set to 'mt_house_same' or 'mt_house_zero'
16:21:32 <Alberth> ie know what you get without needing to test
16:22:18 *** quorzom has joined #openttd
16:22:30 <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
16:23:30 <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
16:24:53 <Alberth> well, you can't stop a river in one day, so perhaps your solution is the best temporary solution.
16:25:49 <Alberth> just pointing out the way of the python to you in an ideal world
16:26:14 <Elyon> and that is much appreciated
16:26:14 <Eddi|zuHause> what kind of saying is that? :p
16:26:21 <Eddi|zuHause> have your people tried to stop rivers? :p
16:26:43 <Alberth> sea counts too? we did that
16:30:10 *** Klanticus_ has joined #openttd
16:33:33 *** Elyon is now known as Guest1161
16:35:04 <Eddi|zuHause> most sane clients allow you to log into a file
16:36:06 <Elyon> I don't like keeping logs anywhere but in ram
16:43:15 <Alberth> the Internet will keep it for you :)
16:46:10 <Sacro> zapotek.paivola.fi/~terom/logs/
16:47:46 *** Kurimus has joined #openttd
16:51:36 *** Pensacola has joined #openttd
16:53:48 *** TheMask96 has joined #openttd
16:58:06 *** oskari89 has joined #openttd
16:59:14 <Elyon> childsprite with xoffset < 0? Are grfauthors expected to 2-complement the offset themselves?
17:00:50 <Alberth> unless nfo has a unary -, yeah, I'd expect so
17:01:22 <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
17:01:32 <Alberth> oh, just use unary minus
17:02:43 <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
17:03:03 <Elyon> if anything it seems like an oversight to me
17:03:12 <Alberth> sounds like a bug indeed
17:04:06 <planetmaker> Elyon, fix the bug while you're at hacking at NML ;)
17:04:08 <Elyon> I'll modify the one line for it in a patch, seems a better solution than to work around a bug
17:04:55 <frosch123> the childoffsets are not always signed
17:05:42 <frosch123> i think in newgrf context they are signed for objects/industries/..., but unsigned for stations :)
17:06:09 <frosch123> traditionally offsets in ttd spritelayouts have been unsigned, since negative offsets do not work anyway
17:06:19 <frosch123> newgrf made them signed, though negative offset still fail
17:06:58 <frosch123> so the signedness depends on whether some ttdp guy decided to call a new function to fallback to an old one
17:07:01 <Elyon> I used negative pixeloffsets just the other day
17:07:26 <Elyon> we're talking childsprites here, right?
17:09:37 <frosch123> hmm, wait, it's the other way around
17:09:55 <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?
17:10:00 <frosch123> it's signed for stations in built-in layouts, and unsigned for the rest
17:10:32 <frosch123> unless the pixels are transparent anyway
17:11:55 <Elyon> well, negative pixeloffsets are required for defining childsprites of station platforms in a meaningful way
17:11:56 <frosch123> wrt. the signedness: DrawCommonTileSeq has a child_offset_is_unsigned parameter, which is used in hysterical consistent ways
17:12:42 <frosch123> wrt. the flickering: AddChildSpriteScreen skips the sprite, if the parent was clipped
17:13:11 <frosch123> Elyon: currently you have to make parent sprites big enough by adding transparent pixels, so they include all their child sprites
17:13:37 <frosch123> but :) since i grew tired of explaining that to every newgrf author from scratch, it may be better to change ottd :)
17:14:07 <Elyon> V453000: are you reading this?
17:14:16 <frosch123> we had the same issue in yeti :)
17:14:26 <frosch123> and ogfx, and ... :p
17:15:34 <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?
17:15:45 <frosch123> sometimes you just have to drop some ttd shenanigans :)
17:16:03 <frosch123> Elyon: yes, something silly like that :)
17:16:22 <Elyon> wow, okay. I hope you don't judge me too harshly for not figuring that out myself :p
17:16:36 <Elyon> I'll leave the validator as it is, then
17:19:33 <Alberth> hmm, no of course, nml has no station support, silly me
17:19:54 <frosch123> no idea whether anyone needs offset >= 128
17:23:06 <Elyon> now we just need to set and check callbacks for differing spriteset/spritegroups
17:23:22 *** TheDude has joined #openttd
17:26:49 *** Quatroking has joined #openttd
17:30:08 *** MTsPony has joined #openttd
17:30:16 <TheDude> I wanted to make a planet :D
17:30:51 <frosch123> you need to produce a lot of gas first
17:30:54 <frosch123> but please not here
17:31:03 <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?
17:31:35 <frosch123> base language is edited via commits, not via the translator
17:31:48 <TheDude> ok, and for any other language? Do I have to sign up for each individual language?
17:32:11 <frosch123> usually people sign up for the languages they know :p
17:32:36 <frosch123> if you have some other translation for your project, you can always commit translations, and eints picks them up
17:32:36 <TheDude> but even as project manager I have to signup for the language?
17:32:44 *** smoke_fumus has joined #openttd
17:33:13 <frosch123> if you want to use eints to upload other languages, you can assign yourself as "translation manager"
17:33:23 <frosch123> then you can edit all languages in eints
17:33:47 *** FLHerne has joined #openttd
17:34:08 <frosch123> but i would not know a reason to do that
17:35:40 <frosch123> the idea is, that the developers work on the repository, and the translators via the translator
17:35:56 <frosch123> eints picks up updates from the repository and commits changes from the translators
17:36:31 <TheDude> but I still had to sign up as translator for my native language
17:36:58 <frosch123> yes, but you became translator for many projects in that case
17:37:00 <TheDude> I don't see my username in the menu where you pick the roles
17:37:31 <frosch123> you already have a role
17:37:39 <frosch123> click your user on the left and click edit or something
17:37:40 <TheDude> I am just curious about the traslation system
17:48:04 <Elyon> `grep -Rn 'HACK:' nml` => :( :(
17:49:43 <Elyon> anyway station spritelayout sprite properties support arrays of 2 expressions now
18:00:45 *** y2000rtc has joined #openttd
18:01:18 <y2000rtc> Hi all. Can I have one question for you? pls
18:01:53 <frosch123> what's the surface area of the moon?
18:02:56 <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.
18:04:05 <frosch123> ideally you find the source of the newgrf you are using currently
18:04:15 <frosch123> and just alter the speed properties in it
18:04:34 <y2000rtc> Several types of rail is thing of newgrf file?
18:05:00 <frosch123> default ottd only has plain rail, electrified, monorail and maglev
18:05:04 <frosch123> neither of which have a speed limit
18:05:12 <frosch123> anything "slow" is from a newgrf
18:06:22 <y2000rtc> Ok, I will try to find which is the right file. And after this I have to change number of PCX file.
18:07:00 *** itsatacoshop247 has joined #openttd
18:07:11 <y2000rtc> I found it, Nutracks. It was quick. : o )
18:07:24 <Elyon> frosch123: should we use cb14/var10 all the time, or introduce a simpler case for spriteset_num <= 1
18:08:41 <frosch123> Elyon: var10 is always used, but ofc you can skip the test if you have only one choice
18:11:15 <Elyon> it'll increase nml complexity while saving a bit of grf complexity
18:11:39 <y2000rtc> It looks very complicated. : o )
18:11:55 <frosch123> well, then don't do it, one can always add things later :)
18:12:11 <y2000rtc> Maybe will be better to edit nfo file and again compile grf.
18:12:34 <frosch123> if you think that would be easier :p
18:14:18 <y2000rtc> I checked nfo file and is not easier. : o ) Ok next night with editing.
18:23:30 <Alberth> but it's so much more fun when you add a few files
18:24:21 <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)
18:24:50 <Alberth> If I had to find it, I would also have to look through all files
18:28:58 <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, ...
18:29:43 <Eddi|zuHause> i'm sure i forgot a few steps :p
18:36:39 *** tycoondemon has joined #openttd
18:43:06 *** itsatacoshop247 has quit IRC
18:43:19 <Wolf01> mmh, I just purchased the "new 3DS ambassador edition", I wonder if I could resell it :P
18:44:38 <y2000rtc> I tried to cantct someone from team for creating of Nutracks. I will see.
18:45:06 <frosch123> Wolf01: is it that crappy?
18:45:59 <Wolf01> no, I'm wondering if it's bound to my account and if not how much to ask :P
18:47:27 <frosch123> ah, somewhen nintendo things were region locked at least
18:47:40 <frosch123> but those things change randomly all the time :)
18:47:54 <Wolf01> I think it's still region locked, but nintendo had plans to remove it
18:48:25 <Wolf01> I don't remember if directly on the "new 3DS" or with an update to the old 3DS too
19:02:54 *** andythenorth has joined #openttd
19:19:30 *** Myhorta has joined #openttd
19:39:45 *** luaduck is now known as luaduck_zzz
19:52:24 *** FLHerne has joined #openttd
20:03:57 *** Suicyder has joined #openttd
20:18:16 <frosch123> we ran out of anticipated station bear traps
20:18:23 <frosch123> now we need to actually fall into them
20:20:03 <Alberth> we also seem to be running low on problems in busy bee :p
20:22:09 <andythenorth> problems to play, or problems to fix?
20:23:51 <Alberth> no idea how to do that though :)
20:24:09 <Alberth> gives you goals to achieve
20:24:25 <andythenorth> don’t we just stick it on bananaramas?
20:24:25 <Alberth> deliver 50 tonnes coals to power plant
20:24:43 <Alberth> or 6,400 mail to blabla city
20:24:45 <andythenorth> probably needs LICENSE.txt
20:25:04 <andythenorth> release it, say it’s a proof of concept
20:25:12 <Alberth> reach one, and you get a new one
20:25:14 <frosch123> Alberth: i would advertise the "make bananas" method from silicon valley :p
20:25:49 <Alberth> andythenorth: I added licenses to the code files recently
20:26:14 <Alberth> may also need a readme, I guess
20:27:40 <Alberth> :O we don't have a Makefile yet :p
20:28:06 <andythenorth> copy one from frosch123 ? :P
20:28:25 <frosch123> "bundle" and "bananas" are the only targets
20:28:49 <frosch123> i copied it from pm, and deleted all i did not need
20:29:06 <frosch123> hence all the weird _E and _V :p
20:29:40 <Alberth> yeah, I wondered whether we'd need them :p
20:31:42 <andythenorth> hmm forums fund raiser isn’t done yet
20:32:35 <frosch123> it took a half year somewhen
20:33:58 *** FLHerne_ has joined #openttd
20:37:50 <frosch123> Alberth: btw. i heard eints is a great tool to translate gs :p
20:38:09 <frosch123> STR_LAKE_NEWS :There are {NUM} {}fish here <- what are the fish for though?
20:38:34 <andythenorth> oh that popped up some fishing news every 500 ticks or so
20:39:02 <Alberth> add news for achieved goal?
20:39:18 <frosch123> count score in fish?
20:39:31 <andythenorth> like those stupid badges in casual games
20:39:36 <andythenorth> most pointless reward mechanic :P
20:48:10 *** Myhorta has joined #openttd
20:59:44 *** gelignite has joined #openttd
21:00:06 *** Myhorta[1] has joined #openttd
21:11:26 *** FLHerne__ has joined #openttd
21:12:05 *** FLHerne__ is now known as FLHerne
21:15:08 *** zeknurn has joined #openttd
21:42:09 <planetmaker> Elyon, why a tooth as nml icon?
21:44:29 <planetmaker> still don't get it :)
21:45:14 <Taede> enamel sounds similar to nml, its the hard stuff on your teeth
21:45:47 <planetmaker> as such it makes sense :)
21:47:59 *** supermop has joined #openttd
21:48:01 <Elyon> nml pronounced as a single word would be homophonal (??) with enamel, well almost
21:50:29 <planetmaker> I like the idea :)
21:50:39 <Elyon> it was mostly a joke :p
21:50:46 <Elyon> I doubt nml needs an icon anyway
21:51:39 *** zeknurn` has joined #openttd
21:51:54 <planetmaker> it doesn't need one. But could have one ;)
22:03:09 *** Biolunar has joined #openttd
22:06:41 *** Progman has joined #openttd
22:09:05 *** andythenorth has left #openttd
23:01:17 *** itsatacoshop247 has joined #openttd
23:48:22 <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 :->
23:49:57 <Elyon> well we stopped a few hours back
23:50:05 <Elyon> some hours back, probably 6-8 hours
23:50:28 <dreck> actually...thats a good question..where did the expression "a brick wall of text" really come from....
23:50:35 * dreck wonders if theres an answer online
23:50:35 <Elyon> the nml station specs are getting fleshed out
23:50:44 <Elyon> it's just a wall of text, not a brick wall
23:50:55 <Elyon> brick walls are for head-running-against
23:52:29 <dreck> "to relieve stress bang your head on the red circle" aka target circle taped to a hard wall
23:52:40 <dreck> silly thing that one..I've actually see a few of these kind in person
23:53:01 <dreck> stress != physical headache heh
23:53:27 <dreck> anyway elyon what're you doing atm?
23:54:16 <Elyon> programming with visitor
continue to next day ⏵
