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

---Logopened Fri Jan 09 00:00:19 2015
00:04-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has joined #openttd
00:56-!-Eddi|zuHause [] has quit []
00:56-!-Eddi|zuHause [] has joined #openttd
01:45-!-MTsPony [] has quit []
01:59-!-DDR [] has quit [Read error: Connection reset by peer]
01:59-!-DDR [] has joined #openttd
02:15-!-Supercheese [] has quit [Read error: Connection reset by peer]
02:15-!-Supercheese [] has joined #openttd
02:15-!-luaduck_zzz is now known as luaduck
02:23-!-DDR [] has quit [Ping timeout: 480 seconds]
02:45-!-liq3 [] has quit []
03:32-!-pxr [] has quit [Read error: Connection reset by peer]
03:34-!-Yotson [~Yotson@2001:980:6ac8:1:2c9d:199a:48c9:8080] has joined #openttd
03:54<Flygon> Anyone got any ideas what's happened? O_o
03:56<+michi_cc>Flygon: Look closely where the reserved path of the train in the lower platform ends. And then rid yourself of the wrong conception that stations supposedly have built-in signals.
03:57<Flygon>Holy crap
03:57<Flygon>Thanks O_O
03:57<Flygon>This explains a LOT
03:57<Flygon>Thanks, man
03:59-!-HerzogDeXtEr [] has joined #openttd
04:03<V453000>moooin, RAWRin, PURRin, NUTTin
04:08-!-supermop [] has quit [Ping timeout: 480 seconds]
04:15-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
04:15-!-HerzogDeXtEr [] has joined #openttd
04:54-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:a84b:553b:8385:1f02] has quit [Ping timeout: 480 seconds]
04:57-!-Supercheese [] has quit [Read error: Connection reset by peer]
04:57-!-Supercheese [] has joined #openttd
05:08-!-Supercheese [] has quit [Read error: Connection reset by peer]
05:09-!-Supercheese [] has joined #openttd
05:33-!-jjavaholic [] has quit [Remote host closed the connection]
05:49*Eddi|zuHause opens a mystery folder called "~/zeug/backup" ["zeug"="stuff"]
05:58-!-frosch123 [] has joined #openttd
06:30<@peter1138>And that was the last we ever heard from Eddi|zuHause...
06:34-!-glevans2 [] has quit [Ping timeout: 480 seconds]
06:35-!-supermop [] has joined #openttd
06:36-!-glevans2 [] has joined #openttd
06:46-!-sla_ro|master [slamaster@] has joined #openttd
07:32-!-Supercheese is now known as Guest1242
07:32-!-Supercheese [] has joined #openttd
07:38-!-Guest1242 [] has quit [Ping timeout: 480 seconds]
08:46-!-supermop [] has quit [Ping timeout: 480 seconds]
09:10<Elyon>frosch123, I have a few questions regarding the updated issue
09:18<Elyon>first building, `yextent: 4; // automatically extended to [4, 16], since 16 is the default for extent` <- does this not also mean that xextent will automatically become [16, 4] as the x/yoffset is swapped?
09:19<Elyon>childsprite, `yoffset: -16;` <- I thought we established that we should avoid signed offsets for now?
09:19<Elyon>furthermore, why shouldn't `sprite` be allowed as an array?
09:20<Elyon>and why must sprite be a compile-time constant? Shouldn't global-sprite-number be possible to assign as a runtime expression?
09:22-!-smoke_fumus [~smoke_fum@] has quit [Quit: KVIrc 4.2.0 Equilibrium]
09:23<frosch123>wrt. xextent: [16,4]: yes
09:24<frosch123>wrt. childsprite offset: yes
09:24<Elyon>`sprite: [platforms_set, var44 & 0x07 == 0x07 ? 3456 : 4321]` seems weird, yet supposedly both valid and should be possible to implement?
09:25<frosch123>wrt. sprite: that's what index is for, for global sprite numbers it does not really matter though whether index or sprite is used
09:25<Elyon>you might want a custom sprite for X-oriented but a global sprite for Y-oriented?
09:25<frosch123>i thought "sprite" should not be an array, since that requires checking the orientation for the spriteset/spritegroup reference
09:26<frosch123>anyway, allowing "sprite" to become an array is in theory possible, but i don't consider it nice, and i don't consider it necessary :)
09:27<frosch123>i really don't like testing the orientation in varact2 :p
09:27<Elyon>why does it require that? Wouldn't we just resolve with var10 := spriteset_number on the X-orientation and without var10 set on the Y-orientation?
09:27<frosch123>though argueably you could assign different var10 to it
09:27<frosch123>also fine for me
09:29<Elyon>anyway, sprite-as-array decision notwithstanding, I think the spec is fairly implementable at this point then. However!
09:29-!-Suicyder [~Suicyder@] has joined #openttd
09:29<Elyon>`yoffset automatically extended to [12, 0]` => also `xoffset := [0, 12]` yes?
09:30<frosch123>if we do the automatic swapping, then i guess we need to do it in all cases
09:30<Elyon>finally, "The Y orientation is added automatically" <- this is for simplifying the implementation so that `forall spritelayouts with feature == 4, all props except sprite and palette are guaranteed arrays`?
09:31<frosch123>if it's to confusing, we could also drop the automatic swapping though
09:31<Elyon>I think the swapping is a use-case that will almost always be relevant
09:32<frosch123>yes, but it is also confusing since you need to specify the values for the X orientation (arbitrarily choosen over Y)
09:32<Elyon>in that most stations have platforms, and most platforms are (or ought to be) buildingsprites, and most platforms-as-building-sprites will need X-orientation (x|y)(offset|extent) values that need to be swapped for Y-orientation
09:33<frosch123>wrt. the automatic addition of Y direction: the spritelayout must define both. so, if Y is missing, what else can you do but add it automatically?
09:33<Elyon>X-orientation is the first (left) orientation in the purchase menu
09:34<Elyon>frosch123: well, what I've done currently is `if hasattr('values', value): value: value.values[1]`
09:34<Elyon>so that for arrays, it selects index 1, and for anything not a value it just keeps that value
09:34<Elyon>two different means to the same end
09:35<frosch123>but isn't that the same as: if you specify one value, it is used for both X and Y ?
09:35<frosch123>(though possibly swapped)
09:36<Elyon>I don't know which approach is neater; expanding to array in property validators when feature == 4, OR checking for array and extracting value[1] iff property is array
09:36<Elyon>they are the same end result, yes - but which is the most sensible implementation?
09:36<frosch123>oh, also about swapping: it gets more weird, if the user does "xoffset: [12, 4]; yoffset: 5"
09:36<frosch123>here the 4 and 5 somewhat contradict
09:36<Elyon>hmm ...
09:37<frosch123>Elyon: sorry, i cannot give you implementation recommendations :) you probably know that part of the code better than me
09:38<Elyon>not necessarily. Anyway, expanding every property to and array complicates the validators but simplifies the layout-duplicator
09:39<Elyon>and my thought was that the value is swapped, yet the swap only actually happens for a specific orientation if that value isn't explicitly set
09:39<frosch123>so, well, i am not sure about the swapping :) it looks useful, but can also result in quite weird effects
09:39<Elyon>so, `xoffset: [12,4]; yoffset: 5` => `xoffset: [12,4]; yoffset: [5,12]`
09:40<Elyon>ie. the swap only sets the value if the value is not already explicitly set
09:40<Elyon>that seems the most sensible to me
09:40<Elyon>`if user sets value: use value else: use swapped`
09:41<Elyon>that way we keep the best of both worlds without having surprising results for any of the swapping
09:41<Elyon>or at least minimally surprising
09:41<Elyon>I'd like to keep the swapping though since it'll be used in what, 95% of cases?
09:42<Elyon>or rather, 95% of non-default (x|y)(offset|extent) cases, you will want the swap to happen
09:43<Elyon>if the values are default then it swaps `16` and `16` which is pretty expected result anyway :P
09:43<Elyon>(for xextent that is)
09:44-!-Defaultti [] has quit [Quit: Quitting.]
09:44<Elyon>I think that honouring authored explicit values makes the swap "not weird"
09:44<frosch123>the default values are 16, 16 for the extent, which would match for non-track tile
09:44<frosch123>for track tiles you have to set xoffset and xextent already, setting the others only adds two more lines
09:45<frosch123>so, it does not safe that much, does it? anyway, swapping is fine
09:45<Elyon>it does save quite a lot
09:45<frosch123>fine, cats will show anyway, what's used
09:45-!-Defaultti [] has joined #openttd
09:46<Elyon>for two full platforms (the case in ~90% of station-track-tiles I think), you can specify `yextent: 4` for the top platform and `yextent: 4; yoffset: 12` for the bottom platform
09:47<Elyon>as opposed to `yextent: [4, 16]; xextent: [16, 4]` for top and `yextent: [4, 16]; xextent: [16, 4]; yoffset: [12, 0]; xoffset: [0, 12];`
09:48<Elyon>the latter (the 90% use case) seemingly introducing a tonne of redundancy
09:49<Elyon>like, every single `4`, `16` and `12` are referring to /the same logical value/ in 90% of use cases, so duplicating it for every (x|y)(offset|extent) seems both excessive and redundant
09:49<Elyon>redundancy is an error vector
09:50<Elyon>there are four `4`s, four `16`s, two `12`s and two `0`s
09:51<Elyon>whereas with inferrence and autoswap, that becomes two `4`s and one `12`
09:51<frosch123>true, with the swapping you get rid of all 0 and 16
09:51<Elyon>as well as the /need/ to specify xextent every time you specify yextent
09:51<Elyon>I figure the way for the author to consider spritelayout for station is that they define:
09:52<Elyon>1) layout as X-orientation
09:52<Elyon>2) optionally for each param explicitly provide a value for Y-orientation
09:52<Elyon>3) and 2) is inferred sensibly if omitted
09:53<Elyon>the swap approach adheres to the 'DRY' and 'convention over config' philosophies
09:53<Elyon>both of which reduce number of errors /and/ codelines/complexity
09:54<Elyon>like, in the explicit case if you want to change the extents from [16, 4] to [15, 3] ... you have to change the 16 -> 15 four times, and same applies for the 4 -> 3
09:55<Elyon>introducing a high likelihood of mistakes compared to specifying each value just once
09:56<Elyon>makes code less errorful, more maintainable - I can't really think of a reason /not/ to do inferrence/swap :p
09:56<Elyon>s/code/nml code
10:02<Elyon>also, for maximum customisability: it should be possible to support 7 spritesets/groups per layout /per orientation/ without checking orientation in a varact2
10:03<Elyon>wait, no, it wouldn't
10:03<Elyon>7 sprite(sets|groups) in total for one layout. Should be enough anyway
10:04<frosch123>yes, it should be very unlikely that X and Y use different sets/groups
10:05<frosch123>i would expect at most: 1 set for ground, 1 for buildings, 1 for palettes
10:05<Elyon>yeah possibly
10:05<frosch123>hmm, maybe 1 for cargos
10:05<frosch123>still 4 instead of 7 :)
10:05<Elyon>but even then, I still think we should support sprite-as-array
10:05<frosch123>sure, it's more
10:05<Elyon>while still keeping the hard cap of 7 spritesets per layout
10:06<Elyon>for example, imagine ...
10:06<Elyon>spriteset x_platforms { ... }
10:06<Elyon>spriteset y_platforms { ... }
10:06<Elyon>then building { sprite: [x_platforms, y_platforms]; }
10:07<Elyon>so long as the author stays <= sets/groups in total I don't see why we shouldn't support that
10:07<Elyon>doesn't require orientationchecking, just requires setting var10 differently for the two layout orientations
10:07<Elyon>/in/ the layouts
10:10<Elyon>I can imagine ground: 1set, buildings: 2set, platforms: 2sets, palettes: 2sets, cargos: 1set - this is 8 sets in total
10:10<Elyon>so the hardcap of 7 might very well be reached if your platforms and buildings are in separate spritesets per orientation
10:11<frosch123>i guess we can write the documentatio accodingly
10:11<Elyon>and even with platforms in same set, and buildings in a different set, we still reach 5 used sets
10:11<frosch123>and recommend alternating orientations within spritesets :)
10:12<Elyon>so 5 used sets for a fairly logical separation of spriteset graphics files - and this isn't even considering any grf-specific usecases which might very well end up using another set or two
10:13<Elyon>point being we should encourage or at least allow logical separation of spritesets
10:14<Elyon>for cats for example, the graphicswill probably be separated into [groundset, buildingset, platformset, paletteset, cargoset, signalset] at the very least
10:14<Elyon>maybe an additional `fluffset` as well, in which case we would exactly hit the 7 set limit
10:16<Elyon>anyway, I shall adhere to the tentative undocumented suggestions and decisions we have discussed now :p
10:19<@planetmaker>but one spriteset can hold 255 sprites, can't it?
10:19<Elyon>a spriteset can hold at lot more I think
10:19<@planetmaker>thus I don't see 7 spritesets as a real limit in that case (though I'm sure someone would find it ;) )
10:20<frosch123>yes, 64k per spriteset
10:20<Elyon>it's not a limit, but encouraging/supporting a logical separation of sprites into different sets seems like a good approach to me
10:21<@planetmaker>hm, no idea why that would be needed and why I would separate them into different spritesets. Why is it good?
10:21<Elyon>if you absolutely desperately /need/ more than 7 logical separate sets you will have to combine some of them into <= 7 primary separate sets
10:22<Elyon>pm: logical separation means better code readability
10:22<@planetmaker>My approach to spritesets is to use one big one and reference the sprites by offset (or name)
10:22<@planetmaker>true, that might be
10:22<@planetmaker>but you can name sprites in spritesets :)
10:23<Elyon>`sprite: cargo; index: 14` is more readable than `sprite: all_mai_spraits; index: 14777`
10:23<frosch123>planetmaker: not all sprites use little/lots variations
10:23<Elyon>pm, wait what?
10:23<frosch123>the sprites that use little/lots need to be a in a different set, than those who do not use little/lots
10:23<Elyon>individual sprite LABELLES?!
10:24<Elyon>this. is. amazing.
10:24<frosch123>no, i think there were names for spritesets in spritegroups
10:24<Elyon>frosch123: "Each sprite may be prefixed with a label"
10:24<frosch123> <- hmm, or maybe there is
10:24<Elyon>means we can have nmlcode like this:
10:25<Elyon>`sprite: concrete_platform_sprite; index: [2,3];`
10:25<Elyon>instead of `sprite: platforms; index: [14, 15];`
10:25<Elyon>self-documenting code!
10:26<frosch123>that won't work for spritegroups though
10:26<frosch123>since you need to reference the spritegroup, but the label is in the spriteset
10:26<frosch123>when using spritegroups, it's the job of the user anyway, to make sure the spritesets are in sync
10:27<Elyon>chances are you won't need/don't know specific sprites at compile-time for little/lots anyway
10:27<@planetmaker>sprite: groundtile_spriteset(this_groundtile_label)
10:27<Elyon>pm, is that the syntax?
10:27<@planetmaker>I think that's how you would reference the sprite with that label, yes
10:27<Elyon>ah okay
10:28<Elyon>so `sprite: platforms(concrete)`
10:28<Elyon>index: [0, 1] as well probably
10:28<@planetmaker>the usual approach to reference the n-th sprite in a spriteset is: sprite: spritesetname(index);
10:28<@planetmaker>where index is the sprite (starting 0-counting) you want to reference in the spriteset
10:29<Elyon>frosch123: what do you think of allowing spriteset/spritegroup indexing/labelusing in the end anyway?
10:29<@planetmaker>index could also be an expression like tileslope + 18 * anim_stage
10:29<frosch123>it would be nice, but i have no idea how it could possibly work with spritegroups :)
10:29<Elyon>would allow for sprite labels, AND simplify `index: [0, 1]` in most cases, AND make code inherently readable without comments
10:29<frosch123>planetmaker: index works differently for stations
10:30<Elyon>so an elaborate example of what I think we /should/ support:
10:30<frosch123>"sprite: plaforms(concrete + [0,1])" resp. "sprite: plaforms(concrete) + [0,1]" is too weird/complicated, hence we split "sprite" and "index"
10:30<frosch123>but now we are about adding two indices :p
10:31<frosch123>(though argueably for global sprites we already have two indices)
10:31<@planetmaker>frosch123, yes, I fear the differences :)
10:31<@planetmaker>it's a big PITA that stations are so different from the rest
10:31<Elyon>well in fairness, we would encourage the sprite index as an absolute offset, and the index property as the relative offset
10:31<@planetmaker>maybe grf v9 should introduce an identical way for them :P
10:32<frosch123>planetmaker: nope, we abstracted it already, so it is the same
10:32<Elyon>`sprite: platforms(concrete + variant); index: [0, 1];`
10:32<frosch123>just that stations have orientations, while houses have not
10:32<frosch123>and that stations are expected to look the same in both orientations, while objects are entirely different
10:32<Elyon>^ what do you think of that supported indexing feature?
10:32<@planetmaker>can you remind me: this index... what does it index?
10:33<frosch123>it's the parameter to the spriteset
10:33<frosch123>just that there are two: for both orientations
10:33<Elyon>spriteset/spritegroup offsets to find the absolute position within the set/group, and index property to offset slightly within the logical subseparation
10:33<@planetmaker>nah, then: sprite: [spritesetname(xsprite), spritesetname(ysprite)]
10:34<frosch123>also, there is the little/lots thingie, which neither houses nor objects have
10:34<@planetmaker>that's imho more accessible
10:34<Elyon>planetmaker: huh
10:34<@planetmaker>if you need an x and a y sprite for each
10:34<@planetmaker>less boilerplate
10:34<@planetmaker>and no absolute and relative maths combined
10:34<Elyon>and we'd avoid introducing a new property
10:34<@planetmaker>why new property?
10:34<Elyon>`index: ` is a new property
10:35<frosch123>planetmaker: isn't that syntax completely redundant?
10:35<Elyon>a pseudoproperty, at that
10:35<@planetmaker>frosch123, how so? One for the x-orientation sprite, one for the y-orientation? (I might miss some crucial step)
10:35<frosch123>you put "spritesetname" twice
10:35<frosch123>also, "spritesetname" is wrong, it is "spritegroupname"
10:36<Elyon>pm's suggestion seems solid to me. Also allows referincing different spritesets/groups based on orientation
10:36<frosch123>and parameters to spritegroups are very confusing, "index" is imho way supperious
10:36<Elyon>frosch123, really?
10:36<@planetmaker>frosch123, it's just a $spritesetname1 - whatever name it has
10:36<frosch123>let's make a proper example with spritegroups
10:36<Elyon>pm made a valid point in that having two indices, one absolute and one relative, is a bit overkill
10:37<Elyon>I think two indices is /more/ rendundancy than potentially referencing the same spriteset/group twice with different indices
10:37<Elyon>s/indices/index properties/
10:37<frosch123>"index" selects the sprite in station2..4
10:37<frosch123>puting it in () behind "spritegroup2" would suggest it would select little/lots
10:37<frosch123>which it does not
10:38<Elyon>hmm ...
10:39<frosch123>putting any parameter after the group makes it very weird to me; besides that i think "index" is way easier to implement
10:39<frosch123>since it makes it easier to detect when var10 can be shared
10:40<frosch123>planetmaker: where is little/lots in that example?
10:40<@planetmaker>ah :)
10:40<@planetmaker>nowhere yet
10:40<Elyon>`sprite: platforms(concrete + variation); index: [0, 1];` => platform set selection, concrete platform setsection selection, concrete platform variant setsection selection, orientation offsetting
10:41<Elyon>seems ideal from a code readability/low redundancy point of view
10:41<@planetmaker>this little/lots... that's mandatory, yes?
10:41<Elyon>it's mandatory to support, but generated by default if you reference spritesets instead of spritegroups
10:41<frosch123>planetmaker: that's how stations work :p
10:42<@planetmaker>yeah, sorry, I need to ask. I don't know how they work :)
10:42<@planetmaker>why does the 'little' only reference one spriteset in your layout?
10:42<frosch123>industries/houses have construction stage, objects have view; but stations have two properties: orientations and cargo amount
10:43<frosch123>[16:42] <planetmaker> why does the 'little' only reference one spriteset in your layout? <- so i had less to type?
10:44<@planetmaker>hm... then I don't get how the spritegroup works there... shouldn't the amount of sprites be identical?
10:44<frosch123>(actually, cut the "view" for objects, it's not comparable)
10:44<frosch123>planetmaker: inside the spriteset
10:44<@planetmaker>ok, but same amount of sprites for little and lots?
10:44<frosch123>little/lots is just like vehicles loading/moving
10:44<Elyon>anyway, I think the idea of supporting `spriteset(label/index)` is valid, yet doesn't remove the need for the `index: []` property
10:44<frosch123>you do not need the same amount for moving and loading
10:45<frosch123>for closed vans you only have one moving
10:45<Elyon>both approaches have their uses - sometimes concurrently
10:45<frosch123>Elyon: but how to resolve the label?
10:45<frosch123>should the spritegroup inherid the labels from all/the first spriteset?
10:45<Elyon>frosch123, labels are only supported when spritesets are referenced, not when spritegroups are
10:45<frosch123>ok :)
10:46<Elyon>I think that makes the most sense?
10:46<Elyon>with a `TODO:` comment somewhere about supporting spritegroup label inheritance in the future
10:47-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
10:52-!-TheMask96 [] has joined #openttd
10:52<@planetmaker> <-- revised suggestion
10:53<@planetmaker>thus the index is passed-through right to the spritesets
10:53<@planetmaker>if you specify any
10:53-!-pxr [] has joined #openttd
10:53<frosch123>that uses different spritegroupos for x and y, which is exactly what should be avoided :)
10:53<@planetmaker>you can use the same
10:53<@planetmaker>no-one forces you to use different ones
10:53<frosch123>it's also very long
10:53<@planetmaker>just specify the same and different index
10:54<frosch123>stations are designed so both directions work a and look the same
10:54<@planetmaker>and I don't think it's longer than specifying a separate index property
10:54<@planetmaker>it's consistent with how vehicles work with the groups
10:54<frosch123>in your example you distinguish the orientation on the top-level, which nml would have to detect to be identical, or create a hell of a grf :p
10:55<@planetmaker>I don't see the problem?
10:55<frosch123>well, my opinion was to only allow referencing one spritegroup/set independent of orientation
10:55<@planetmaker>you have to distinguish something
10:56<frosch123>elyon argumented that it is not much harder to *allow* specifying them differently
10:56<frosch123>pm makes it the default case, which is imho wrong
10:56<frosch123>following that approach you are back to layoutsgroups from 2 days ago
10:56<@planetmaker>this approach allows you to choose spritesets however you like. And you can pass-through any index like you want. Without any magic
10:56<frosch123>they would make it exactly the same as objects
10:57<frosch123>but the would also not at all enforce x and y to be identical
10:57<frosch123>which is just wrong :p
10:57<@planetmaker>you cannot enforce that anyway at all?
10:57<frosch123>or just no layoutgruops at all, just use the same layout, and let the user check the orientation in a switch
10:58<frosch123>but again, you are completely remoing the built-in mechanic of handling orientations the same
10:58<frosch123>which is just brushing the donkey from the wrong side :p
10:59<frosch123>planetmaker: you are treating stations like objects
10:59<frosch123>objects have a "view" variable, and then allow the newgrf do select a spriteset depending on the view
11:00<frosch123>"view" is a complete grf thing
11:00<frosch123>stations on the other hand have built-in orientations, and everything in ottd is about making them behave the same
11:00-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
11:00-!-mode/#openttd [+o Alberth] by ChanServ
11:00<frosch123>by treating them like "views" you work completely against the logic in ottd
11:01-!-Myhorta [] has joined #openttd
11:01<frosch123>the "orientation" thus must be the very last switch in nml
11:01<frosch123>not the 3rd last after set, group and custom offsets
11:02<@planetmaker>can you elaborate on the 'must'? What is being lost?
11:02<frosch123>in fact i think "nml" should completely hide the "orientation" aspect
11:03<frosch123>else you end up with tiles that are track tiles in X, and non-track in Y
11:03<@planetmaker>ok... so the spritelayout distinguishes xdir and ydir. And the little/lots is found in the sprite definition?
11:03<frosch123>planetmaker: my_station_x and my_station_y is compeltely redundant
11:03<@planetmaker>vice versa than I specified?
11:03<frosch123>they must be the same to make any sense
11:04<frosch123>but since they are not the same by syntax, nml has to create a hyper-complex distinguishing between the cases
11:04<frosch123>splitting "sprite" and "index" separates the sprite selection from the orientation
11:05<frosch123>sprite comes firs, then little/lots, then index
11:06<frosch123>or to put it differently: the nml syntax should suggest to put orientations alternating into spritesets, since that's the most natural form in the grf
11:06<@planetmaker> <-- so... not like that either?
11:06<frosch123>which benefits everyone :p
11:07<@planetmaker>hm. I don't see why I couldn't have all X first and then all Y :)
11:07<frosch123>planetmaker: i have no idea how to compile that
11:07<@planetmaker>in a spriteset
11:08<frosch123>also "little/lots" are not two entries
11:08<frosch123>anyway, i don't see the discussion going anywhere
11:10<@planetmaker>I really don't see how specifying the index for the y and x orientation separately is any different
11:10<frosch123>because that is how grfs work
11:11<@planetmaker>you want sprite: spritegroup; index: [x, y]; I suggest: sprite: [spritegroup(index), spritegroup(indexy)]
11:11<frosch123>i really cannot explain why "index" is natural, and a random other ordering is not natural
11:11<frosch123>planetmaker: your suggestions are like swapping loading stages and orientations for vehicles
11:11<frosch123>you cannot make nml completely different from grfs
11:11<frosch123>vehicles to not have more power when driving in one direction
11:12<@planetmaker>sailing vessels :P
11:12<frosch123>you cannot define vehicles with 6 directions
11:14<@planetmaker>ok, then I see no way around using absolute offsets into the spriteset and relatives for the index
11:14<@planetmaker>which is... confusing
11:15<frosch123>possibl,y but then i would drop the absolute offset, not the relative ones :p
11:15<@planetmaker>that's ugly. No shared ground tiles or building parts
11:15<@Alberth>group x and y direction together?
11:15<@planetmaker>that's what I try to suggest, Alberth :)
11:16<frosch123>[17:15] <planetmaker> that's ugly. No shared ground tiles or building parts <- i don't follow why that would be the case
11:16<@Alberth>drop "xdir:" and "ydir:", and use [ x-stuff, y-stuff] or so
11:16<frosch123>Alberth: funnily i suggest the same
11:16-!-quorzom [] has joined #openttd
11:17<@Alberth>ok, didn't read backlog :)
11:17<@planetmaker>hm. Maybe no parameter for the spritegroup, but like: (I know that not all slopes make sense)
11:18<@planetmaker>index then being an absolute entry into the spriteset
11:18<frosch123>planetmaker: that looks exactly what i mean
11:18<@Alberth>line 6 is 1 direction?
11:18<@Alberth>oh, nice
11:23<@planetmaker> <-- less boilerplate that way?
11:24<frosch123>how to do global sprites then?
11:25<@planetmaker>How do you mean? I don't understand your question...
11:25<@planetmaker>you mean it conflicts with the current implementation of sprite:... ?
11:25<Elyon>elaborate example of some of the features we need in CATS, and how I would personally like to be able to define those stations:
11:25<@planetmaker>how is it handled by your approach currently?
11:26-!-TheDude [~Thed@2a02:2b88:2:1::1d73:1] has left #openttd [I'm a happy Miranda IM user! Get it here:]
11:27<frosch123>planetmaker: sprite: GROUNDPSRITE_RAIL_Y; index: [0, -1]
11:27<@planetmaker>not [-1, 0] ?
11:27<Elyon>RAIL_Y index < RAIL_X index
11:28<frosch123>no, funnily Y is before X ni default sprites :p
11:28<frosch123>we also fell over that :)
11:28<frosch123>anyway, the idea is to hide the default track ground including railtype selection in a marco
11:28<@planetmaker>then it would need to be GROUDSPRITE_RAIL_X; index: [0,-1]
11:28<frosch123>it's way to complicated to explain it to grf authors, and there is zero variation
11:29<frosch123> <- see second line
11:29<Elyon>frosch123, mind if I post as a comment/syntax-suggestion on the open issue?
11:30<frosch123>Elyon: it's fine, but i would suggest to paste the content, not only the link, since sp*ke changes it all the time (pun)
11:30<frosch123>also add some bullet points, what changed
11:30<Elyon>frosch123: yes, that was my intention, at least with the full content paste
11:30<frosch123>like "sprite" allowing an array, but not recommending it
11:30<@planetmaker>frosch123, can we have a keyword 'ref_base_sprites' or so and directly give the sprite numbers in the index then?
11:30<@planetmaker>that's less magic than what you quoted
11:31<frosch123>planetmaker: huh? it's a single word "ground_track"
11:31<Elyon>huh, what's happening? isn't spriteset/group reference == customsprite, and constantnumeric == defaultsprite?
11:31<frosch123>there are no parameters or whatsoever
11:31<@planetmaker>sprite: 0; index: [GROUNDSPRITE_RAIL_X, GROUNDSPRITE_RAIL_Y];
11:31<@planetmaker>easier for me to comprehend
11:32<@planetmaker>same thing, though
11:32<frosch123>but it's wrong
11:32<frosch123>no, it's not the same
11:32<Elyon>frosch123, there is no `sprite: array`s in the example there
11:32<frosch123>yuo need to add a offset for monorail and maglev
11:32<frosch123>and you ened to add offsets for snow
11:32<Elyon>groundsprite_rail takes care of at least railtype
11:32<frosch123>or in other words: you need to do exactly what ottd expects to insert railtype graphics
11:32<Elyon>dunno about snow, I was of the expression that it did that as well
11:32<Elyon>it's a magic defaultsprite tbh
11:33<frosch123>so, there is zero variation for the user, and the user should not have to type it at all
11:33<frosch123>planetmaker: stations come with a default offset into the spriteset using the fallback-railtype
11:34<@planetmaker>yes, they do
11:34<frosch123>you never need that, thus the nml syntax disables it, and even disallows using it
11:34<frosch123>except: it is needed for the track ground sprite
11:34<Elyon>frosch123, are you sure? sprite 1012/1011 automagically handles railtype
11:34<Elyon>and groundtype iirc as well
11:35<frosch123>planetmaker: essentially, the macro should do exactly, what SplitGroundSpriteForOverlay() expects
11:35<frosch123>there is no point in letting the grf author do that
11:35<@planetmaker>frosch123, but then your index is relative... not absolute
11:36<@planetmaker>sprite: GROUNDPSRITE_RAIL_Y; index: [0, -1] <===> sprite: 0; index: [GROUNDSPRITE_RAIL_X, GROUNDSPRITE_RAIL_Y] is different?
11:36<frosch123>you miss the "+ railtype-magic"
11:37<frosch123>there is no equivalant to "+ railtype-magic" in the current nml syntax
11:37<frosch123>since it is only needed in that one place, and not wanted by anyone in any other case :p
11:37<@planetmaker>yes... nml does not need that exposed... but could add it. automatically
11:37<@planetmaker>if sprite==0
11:38<Elyon>or sprite is undefined?
11:38<Elyon>ground {}
11:38<frosch123>as said: stations come with a default railtype offset, nml always disables that, because it is stupid. except: the track ground sprite must use it
11:38<@planetmaker>why does it add that automatically with sprite: GROUNDPSRITE_RAIL_Y; index: [0, -1] ?
11:38<frosch123>planetmaker: really, what's your point?
11:39<@planetmaker><planetmaker> sprite: GROUNDPSRITE_RAIL_Y; index: [0, -1] <===> sprite: 0; index: [GROUNDSPRITE_RAIL_X, GROUNDSPRITE_RAIL_Y] is different? <<--- that. I don't see the difference, if there's no magic anyway. Or *where* is the difference?
11:39<frosch123>yes, they are the same, but they are both *wrong*
11:39<frosch123>both are missing *railtype-magic*
11:40<frosch123>that's why there is a speical "ground_track", since that's the *only* place that ever needs that
11:40<@planetmaker>I assumed you pasted a correct and working example
11:40<frosch123>and since it makes no sense to put anything else there
11:40<@planetmaker>ok. That makes sense
11:40*planetmaker hugs frosch123
11:41<Elyon>so tl;dr := "implement ground_track macro, receive tofu"
11:41<Elyon>s/tofu/bacon if desired
11:41<@planetmaker>that was mean. I instantly got hungry :(
11:42<@Alberth>/me shares food
11:42<Elyon>"food, otherwise unspecified"
11:43<frosch123>Elyon: what are those "signal" sprites in cats?
11:43<@Alberth>being virtual food, it automagically transforms to the food type you desire :p
11:43<frosch123>are they protest-signs? "we want a train"?
11:44<frosch123>rampaging yetis waiting for the train?
11:44<@planetmaker>yummi, Alberth :)
11:44<Elyon>well no, I thought of adding a signal that is green when platform is free, yellow when it's reserved, and red when it's occupied
11:45<frosch123>ah, i don't think you can distinguish reserved and occupied though
11:45<Elyon>sure you can
11:47<Elyon>frosch123: var18 bits 3 and 4: "train (enters|leaves) station"
11:47<Elyon>just have to use some clever animation state changes
11:47<frosch123>oh, animation triggers have them?
11:48<Elyon>and it's platform specific as well
11:48<Elyon>exactly as needed
11:48<Elyon>so at a glance even with roofed stations, you can see which platforms are occupied, which are about to be occupied, and which are free :3
11:49<Elyon>perhaps we could even have a red+yellow signal when it's about to become green
11:49<Elyon>for maximum AWE
11:49<@Alberth>shouldn't free be red, as in "being idle now" ? :)
11:50<Elyon>red is "OTHER TRAINS: DON'T GO HERE"
11:50<@Alberth>fair enough
11:50<Elyon>yellow is "other trains: don't go here it's almost occupied"
11:50<Elyon>green: "go here NAO"
11:50<Elyon>red+yellow: "don't go here ... yet!"
11:51<Elyon>or some such silly suggested station supported signalling
11:53<frosch123>yeah, we'll forward all bug reports
11:53<frosch123>about signals mis-behaving
12:01<@Alberth>make it behave like race-start lights?
12:05<Elyon>frosch123: <- adequate? ready for initial implementation?
12:05<frosch123>i have the suspicion, that pass-through trains will just drive through red signals :p
12:06<b_jonas>frosch123: uh... they shouldn't
12:08<Elyon>b_jonas: I think frosch123 is talking about the signalfluff of CATS Adaptive Train Stations, not /actual/ functional signals :p
12:10-!-frosch [] has joined #openttd
12:10<frosch>how rude
12:10<frosch>Elyon: it's certainly a superset of what a first implementation would need :)
12:10<Elyon>wat happn
12:11<frosch>my router ocassionally out-of-mems or so :p
12:11<@Alberth>we have two fr0sches now
12:11<Elyon>we doooo
12:11<frosch>one of them will highlight me on all channels shortly :/
12:15-!-frosch123 [] has quit [Ping timeout: 480 seconds]
12:16-!-MTsPony [] has joined #openttd
12:17<Elyon>frosch: :(
12:18<Sheogorath>O.o another german
12:18<Elyon>with mq, if I want to dequeue a patch, I just qpop it and it keeps the patchfile while removing the queued commit?
12:19<frosch>qpop and qpush move the working copy, not changing the patch files
12:19<Elyon>which is what I want I guess
12:20<frosch>if you want to alter one patch file, you do qpop until the working copy is at that position
12:20<Elyon>I have a half-implemented station-spritelayout-properties-as-arrays patch that I want to unapply, without losing the patchfile (because I will use it as a reference for reimplementing properties-as-arrays properly)
12:20<frosch>then you edit, then you do qrefresh
12:21<frosch>Elyon: qpop will not delete any data
12:21-!-Quatroking [] has joined #openttd
12:22<Elyon>wondarfull, `hg qpop && hg qnew -m 'Feature: spritelayout property array values' station-spritelayout-property-array-values` is probably what I need then :D
12:22<@Alberth>and qrm to delete the partial afterwards
12:23<@Alberth>also, you can load the patches in an editor/viewer from .hg/patches
12:24<Elyon>Alberth: ah, yes :)
12:24<@Alberth>(don't edit them, as you change the file directly)
12:24<@Alberth>unless you want to live at the edge :p
12:24<Elyon>well I had some trouble figuring out how to change the commit-message without editing ".hg/patches/the-patch" directly
12:25<@Alberth>hg qref -e iirc
12:25<frosch>i edit unapplied patch files all the time :p
12:25<Elyon>you're living on the edge then :p
12:26<@Alberth>/me lives at the edge too
12:26<frosch>sometimes editing a patch file before qpush is easier than resolving the conflict afterwards :)
12:26<@Alberth>I even change the @@ numbers :p
12:27<@Alberth>make sure you keep a backup though if they are really important, the patches are not version controlled
12:27<frosch>cool, so i am not the only douchbag ignoring fancy merging tools :p
12:32-!-Taede [] has quit [Ping timeout: 480 seconds]
12:37-!-Taede [] has joined #openttd
12:47-!-quorzom_ [] has joined #openttd
12:47-!-quorzom [] has quit [Read error: Connection reset by peer]
12:47-!-Quatroking [] has quit [Read error: Connection reset by peer]
12:47-!-Quatroking [] has joined #openttd
12:53-!-glx [] has joined #openttd
12:53-!-mode/#openttd [+v glx] by ChanServ
12:55-!-Progman [] has joined #openttd
13:26-!-oskari89 [] has joined #openttd
13:26-!-gelignite [] has joined #openttd
13:30-!-Biolunar_ [] has quit [Quit: yo.]
13:37<@planetmaker>Elyon, hg qrefresh -m "New message" should work, too
13:37<@planetmaker>when the patch is your currently checked-out patch
13:37-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
13:37-!-HerzogDeXtEr [] has joined #openttd
13:43-!-luaduck is now known as luaduck_zzz
13:45-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
13:55-!-Klanticus_ [] has quit [Remote host closed the connection]
13:59-!-oyvind [] has joined #openttd
13:59-!-oyvind is now known as Gather
14:01<Gather>hmm i can find my server on the multiplayer display in openttd but get a timeout when trying to create a company. Any ideas? (running out of the box config .. just running openttd -D)
14:02<Gather>running 1.4.4
14:03<Eddi|zuHause>Gather: timeouts can be set in openttd.cfg
14:03<Eddi|zuHause>(on the server)
14:08<Gather>The server says "The server didn't answer the request" but i guess thats a timeout?
14:12-!-andythenorth [] has joined #openttd
14:21-!-Progman [] has quit [Remote host closed the connection]
14:21<Gather>Eddi|zuHause: hmm i set max_join_time to 10000 and max_download_time to 15000 still same problem
14:22<Eddi|zuHause>have you reloaded the config on the server?
14:22<Gather>Eddi|zuHause: I stopped and started the server
14:22<Gather>but i think i might not be editing the right config
14:22<Eddi|zuHause>you have to stop the server before editing the config, otherwise your changes will be overwritten
14:23<Gather>lets give it a try
14:27-!-liq3 [] has joined #openttd
14:27<Gather>ok atleast its the right config.. changed the name of the server and it worked
14:28<Gather>lets check the fw logs :)
14:33-!-Wolf01 [] has joined #openttd
14:33<Wolf01>hello o/
14:34<andythenorth>lo Wolf01
14:38<Wolf01>andythenorth, do you know somebody who succeeded to build a lego ferris wheel using the 157,5° technic angle elements?
14:39<andythenorth>no but where did you look so far?
14:39<andythenorth>brickshelf? mocpages? flickr?
14:39<Gather>Eddi|zuHause: i wonder if the "The server didn't answer the request" is a timout or infact something else
14:40<Eddi|zuHause>well, it could be a misconfigured firewall/router
14:40<Wolf01>just wikipedia and wolfram alpha for trigonometric formulae to calculate the right length of the beams
14:40<Eddi|zuHause>if you only forwarded UDP protocol, the TCP protocol won't go through
14:41<andythenorth>Wolf01: ?
14:41<Eddi|zuHause>UDP is used for querying the server list, and TCP for the actual game connection
14:41<Wolf01>good one
14:41<Eddi|zuHause>although, usually people misconfigure that the other way around :p
14:43-!-Pereba [~UserNick@] has joined #openttd
14:43<Gather>Eddi|zuHause: gah i gotta get some glasses.. i mistyped the destination ip for tcp in firewall config
14:44<Gather>now its working.. now to get it configured with the setup i usually use
15:00-!-Zuu [] has joined #openttd
15:06-!-andythenorth [] has quit [Ping timeout: 480 seconds]
15:07-!-andythenorth [] has joined #openttd
15:15-!-andythenorth [] has quit [Ping timeout: 480 seconds]
15:20-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
15:27-!-sla_ro|master [slamaster@] has quit []
15:29-!-Haube [] has quit [Read error: Connection reset by peer]
15:32-!-FLHerne [] has joined #openttd
15:51-!-Zuu [] has quit [Quit: Leaving]
15:58-!-smoke_fumus [~smoke_fum@] has joined #openttd
15:58-!-andythenorth [] has joined #openttd
16:12-!-andythenorth [] has quit [Quit: andythenorth]
16:47-!-Suicyder [~Suicyder@] has quit [Quit: HydraIRC -> <- The professional IRC Client :D]
16:54-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Ping timeout: 480 seconds]
17:20-!-frosch [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
17:27-!-pxr [] has quit [Quit: Leaving]
17:53-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
18:22-!-Progman [] has joined #openttd
18:27-!-Pereba [~UserNick@] has quit [Quit: ~ AdiIRC - ~]
18:28-!-Pulec [] has quit [Ping timeout: 480 seconds]
18:31-!-Pulec [] has joined #openttd
18:43-!-HerzogDeXtEr [] has quit [Quit: Leaving.]
18:50<Elyon>any issue with me using Alberth's suggestion of `if hasattr('values', value)` instead of `if isinstance(value, Array)`?
18:55-!-LadyHawk [] has quit [Read error: Connection reset by peer]
18:55-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has quit [Read error: Connection reset by peer]
18:55-!-LadyHawk [] has joined #openttd
18:55-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:f16d:3c7a:3ff5:b6bc] has joined #openttd
18:58-!-oskari89 [] has quit [Read error: Connection reset by peer]
19:12<Wolf01>'night all
19:12-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
19:25-!-Myhorta [] has quit [Read error: Connection reset by peer]
19:55-!-Progman [] has quit [Remote host closed the connection]
20:08-!-FLHerne [] has quit [Quit: There's a real world out here!]
20:41-!-DDR [] has joined #openttd
20:51<Gather>hmm i experience connection drops while saving
20:51<Gather>what can be done?
21:04-!-supermop [] has joined #openttd
21:17<Elyon>humm, not allowing spritesets with different sizes in spritelayouts seems an unfortunate limitation for station layouts
21:19<Elyon>it would be quite useful ie. for compositing platforms, buildings, cargo, fluff sprites in the same layout
21:35-!-Quatroking [] has quit [Quit: Leaving]
21:36-!-Quatroking [] has joined #openttd
21:40-!-glx [] has quit [Quit: Bye]
21:47-!-Quatroking [] has quit [Quit: Leaving]
22:09-!-supermop [] has quit [Ping timeout: 480 seconds]
22:32-!-DDR [] has quit [Read error: Connection reset by peer]
22:33-!-DDR [] has joined #openttd
22:44-!-gelignite [] has quit [Quit:]
22:48-!-DDR [] has quit [Read error: Connection reset by peer]
22:49-!-DDR [] has joined #openttd
22:49-!-Haube [] has joined #openttd
22:54-!-Haube1 [~Michi@] has joined #openttd
23:00-!-Haube [] has quit [Ping timeout: 480 seconds]
23:49<Elyon>why is the newgrf specs for stations so inconsistent with the specs from every other feature? T_T
23:56-!-Haube1 [~Michi@] has quit [Read error: Connection reset by peer]
---Logclosed Sat Jan 10 00:00:20 2015