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