Config
Log for #openttd on 9th June 2018:
Times are UTC Toggle Colours
00:00:03  *** Thedarkb has joined #openttd
01:20:23  *** supermop has joined #openttd
01:23:52  *** chomwitt has quit IRC
01:34:27  *** frosch123 has quit IRC
01:35:03  *** Pikka has quit IRC
01:39:10  *** KouDy has quit IRC
02:23:54  *** glx has quit IRC
02:49:51  *** muffindrake2 has joined #openttd
02:51:41  *** muffindrake1 has quit IRC
02:53:59  *** supermop has quit IRC
03:04:46  *** ToffeeYogurtPots has quit IRC
03:17:54  *** supermop_work has joined #openttd
03:19:00  *** KouDy has joined #openttd
03:20:55  *** supermop_work_ has quit IRC
03:27:10  *** KouDy has quit IRC
03:28:58  *** Flygon has joined #openttd
04:48:54  *** Progman has joined #openttd
04:50:24  *** KouDy has joined #openttd
05:06:02  *** cHawk has quit IRC
05:40:19  *** KouDy has quit IRC
06:14:09  *** andythenorth has joined #openttd
06:18:39  <andythenorth> moin
06:25:19  *** KouDy has joined #openttd
06:30:47  *** Fuco has joined #openttd
06:42:28  *** HerzogDeXtEr has joined #openttd
06:43:53  *** Thedarkb has quit IRC
06:45:23  *** nielsm has joined #openttd
07:09:08  *** cHawk has joined #openttd
07:30:18  *** Wolf01 has joined #openttd
07:30:30  <Wolf01> o/
07:42:24  <peter1138> Offski
07:43:22  <andythenorth> skioff
08:00:26  *** sla_ro|master has joined #openttd
08:27:55  *** planetmaker_ has joined #openttd
08:53:48  *** Wacko1976 has joined #openttd
09:14:11  *** iSoSyS has joined #openttd
09:15:51  *** iSoSyS has quit IRC
09:17:50  *** Wacko1976_ has joined #openttd
09:22:18  *** Wacko1976 has quit IRC
09:54:44  *** Wormnest has joined #openttd
10:20:40  *** synchris has joined #openttd
10:44:46  *** frosch123 has joined #openttd
10:52:42  *** Thedarkb has joined #openttd
11:00:44  *** beno__ has joined #openttd
11:07:18  *** Thedarkb1-X40 has quit IRC
11:08:23  *** nkr has joined #openttd
11:20:02  *** Thedarkb has quit IRC
11:32:17  *** Thedarkb has joined #openttd
11:39:28  *** supermop has joined #openttd
11:40:57  *** Thedarkb has quit IRC
11:47:12  *** tokai has joined #openttd
11:47:12  *** ChanServ sets mode: +v tokai
11:48:29  *** supermop has quit IRC
11:54:08  *** tokai|noir has quit IRC
12:17:54  *** Thedarkb has joined #openttd
12:31:25  *** synchris has quit IRC
12:36:13  *** supermop has joined #openttd
12:40:45  *** nkr_ has joined #openttd
12:43:59  *** nkr has quit IRC
13:00:04  *** andythenorth has quit IRC
13:01:18  *** Thedarkb has quit IRC
14:01:58  *** nkr_ has quit IRC
14:05:40  *** HerzogDeXtEr1 has joined #openttd
14:10:43  *** HerzogDeXtEr has quit IRC
15:13:38  *** Fuco has quit IRC
15:13:41  *** supermop has quit IRC
15:35:56  *** snail_UES_ has joined #openttd
15:40:07  *** heffer_ has quit IRC
15:40:33  *** heffer has joined #openttd
15:50:23  *** sla_ro|master has quit IRC
15:50:45  *** andythenorth has joined #openttd
15:54:00  <andythenorth> in retrospect, changing length on cb36 is bonkers
15:54:15  <andythenorth> if any property should be immutable, it's vehicle length
15:56:16  *** virtualrandomnumber has joined #openttd
16:01:11  <nielsm> isn't it used for "generic multiple unit cars" and the like?
16:01:30  <nielsm> e.g. in the 2cc in NML train set?
16:03:14  <nielsm> (personally I'd rather have only fixed-length train sets, especially for MUs based on real-world material)
16:03:30  *** muffindrake2 has quit IRC
16:05:57  *** muffindrake has joined #openttd
16:07:43  *** rocky1138 has joined #openttd
16:12:41  <planetmaker_> CB36 length changes are used in several trainsets. And I consider it unlikely that it changed in the last 12 months ;)
16:14:27  <andythenorth> it's daft
16:14:38  <andythenorth> it's a legacy of only 128 IDs or whatever in patch
16:19:08  <nielsm> it's also a tool to keep the list of purchasable wagon types manageable from the player's perspective
16:20:28  <nielsm> another solution would be to require the player to "refit" the generic cars to match the train type, and refuse to leave depot unless the car type matches train type
16:21:47  *** stefino has joined #openttd
16:23:57  <stefino> hi all. is possible to refit train set due articulated switch? have a 3 wagon train in base and refit it into 4,5 or 6 wagon long train ?
16:24:31  <nielsm> no, refit can't change the number of cars in a train
16:26:24  <stefino> really? have a feeling that it is possible. So no way...have to build it part by part
16:26:59  *** Flygon has quit IRC
16:31:11  <planetmaker_> stefino, well. Technically that's not possible. But actually a newgrf developer can make it so
16:31:32  <planetmaker_> by introducing invisible wagons. And changing length upon refit
16:33:14  <stefino> planetmaker_:  umm umm...I think that it is easier to make 3 simple wagons (front,middle, rear) and to buy amount of middle wagons what I want.
16:33:40  <planetmaker_> stefino, *that* is the LOT easier way to implement that, yes
16:34:24  <planetmaker_> stefino, and you can even change the look of the wagons, depending on the overall train length, if I recall correctly. Or depending on their position in the train. But that requires no magic with lengths etc and refit
16:36:45  *** Thedarkb has joined #openttd
16:38:17  <andythenorth> you can change look based on position, easily
16:38:57  <andythenorth> nielsm: refitting the generic cars doesn't help the shunting situation much
16:39:23  <stefino> holly sh.t :D this means that my random switch will not work. Cause in articulated  items I have depentent random switches and this is unreal to code between more "solo" trains
16:39:25  <andythenorth> the whole 'cannot attach' situation needs to die for shunting
16:40:32  <stefino> so the 3rd option is to code all sets individualy
16:41:09  <stefino> it takes the same number of purchase list lines
16:41:33  <nielsm> andythenorth, imo there needs to be a concept of "hard couplings" that can be done by a mechanic in a workshop, but not during regular running, it's not entirely uncommon for some MU-like designs afaik
16:42:23  <andythenorth> eddi suggested similar
16:42:34  <andythenorth> but that doesn't help the newgrf spec much
16:42:45  <nielsm> unless you want to entirely prevent newgrf authors from making systems for player-determined-length MUs that logically shouldn't be able to separate during running
16:42:49  <andythenorth> unless it's sandboxed, and changes the behaviour of some vars
16:43:20  <andythenorth> if we sandbox a 'consist' and vehicles can't read outside it, it's fine
16:43:26  <andythenorth> except it breaks grfs
16:44:07  <andythenorth> due to history, grfs are fundamentally in conflict with shunting
16:44:23  <andythenorth> grf world has taken the view that grf author controls the train, not the player
16:49:10  <planetmaker_> oh, is shunting again a thing?
16:49:21  <Wolf01> Shunting is always a thing
16:49:55  <Wolf01> You need it when you can't do it, and it gets boring after 2 times when you can (must?) do it
16:51:18  <nielsm> what is actually needed is for each train car type to have a variable for front-coupler type and back-coupler type (they can be different)
16:51:26  <nielsm> and only cars with compatible couplers can attach
16:51:36  <nielsm> and a coupler type can be hard or soft
16:52:30  <nielsm> or you could even allow coupler types to specify how long it takes to perform the couple/decouple operation
16:53:23  <nielsm> (modern coupling between EMUs might be really quick, attaching an old loco to old goods cards with westinghouse-type brake pipes requires a full brake test)
16:53:28  <Wolf01>  <andythenorth> due to history, grfs are fundamentally in conflict with shunting <- break it, isn't community whining about not being able to do new things because of retrocompatibility?
16:54:51  <andythenorth> nielsm: nah, I think you solve wrong problem
16:55:01  <andythenorth> what problem do you try to solve? :)
16:56:34  <planetmaker_> When I ponder(ed) shunting I considered yet another newgrf flag, set at global level by the trainset: [x] allow shunting
16:56:34  <nielsm> I'm just offering a solution in search of a problem!
16:57:08  <planetmaker_> Then the vehicles defined there support it. That's it. If you set that flag, you are limited to a certain amount of things, but will not be able to do "magic" or "atrocities" (depending on view)
16:57:40  <andythenorth> planetmaker: I think it has to be something like that
16:58:08  <nielsm> although you might really want to prevent players from doing stuff that shouldn't be possible, like having an EMU passenger train pick up a line of coal cars, or having an old EMU model coujple to a new one that isn't compatible IRL
16:58:17  <andythenorth> then 'can attach' needs extending to handle shunting
16:58:22  <andythenorth> with messages for player
16:58:29  <andythenorth> also it needs to account for conditional orders
17:01:20  <nielsm> yep, news item "train attempted to couple with incompatible unit" and train pauses until you skip the join order or remove the offending cars and put something else instead
17:01:20  <nielsm> and then you need to handle the case of two trains that were supposed to join but couldn't occupying the same platform in station, so they can't just leave in either direction
17:02:41  <planetmaker_> <nielsm> although you might really want to prevent players from doing stuff that shouldn't be possible, like having an EMU passenger train pick up a line of coal cars, or having an old EMU model coujple to a new one that isn't compatible IRL
17:02:54  <planetmaker_> ^^ I don't think you want to prevent players doing that
17:03:20  <planetmaker_> well, maybe you. But I don't. The solution to that problem is simple: if you don't want that to happen, then don't order your vehicles to do so
17:03:41  <planetmaker_> so every realism-based player can play happily. And everyone who doesn't care, can still do what they like
17:03:42  <Wolf01> +1
17:04:05  <nielsm> then you make a mistake with your orders and end up "why the heck is train EMU hauling around the coal???"
17:05:26  <nielsm> (and "what's that EMU doing at the coal mine?")
17:05:26  <planetmaker_> so fix that mistake and you can continue to play happily
17:05:43  <planetmaker_> basically you ask for the game to make decisions you like for everyone - irrespective if it suits them or not :)
17:06:21  <virtualrandomnumber> what would happen if I ordered a train to pick up wagons at a station but the wagons in question aren't there?
17:06:46  <planetmaker_> it's to me like lego: I can build realistic-looking things with the bricks. If I mis-place something, I dissasemble it, fix it and re-assemble
17:06:57  <planetmaker_> But at the same time I could build my sci-fi universe with it.
17:09:48  <andythenorth> nielsm: yes incompatible trains should stop
17:09:53  <andythenorth> and report
17:10:07  <andythenorth> like when they can't find a path and get stuck in a block
17:10:48  *** Thedarkb has quit IRC
17:13:37  <Eddi|zuHause> <planetmaker_> ^^ I don't think you want to prevent players doing that <-- well, we do have the "can attach" callback for that, but that kinda assumes you're inside a depot
17:16:28  <andythenorth> that needs extending for shunting
17:19:48  <Eddi|zuHause> exactly
17:19:58  <andythenorth> the key objective is to ensure that trains remain built as newgrf authors want
17:20:11  <andythenorth> otherwise it's a spec violation
17:20:23  <andythenorth> it's not up to the player to compose trains
17:20:30  <planetmaker_> :P
17:21:00  <Eddi|zuHause> well it is, but when the newgrf author wants to put restrictions on it, we should respect those
17:21:21  <andythenorth> I would be trolling, but I'm not
17:21:31  <Eddi|zuHause> sometimes more restrictions make for better gameplay
17:21:33  <andythenorth> historical fact is that newgrf spec exists to let newgrf authors control player behaviour
17:21:44  <andythenorth> unless we bump version
17:23:14  *** virtualrandomnumber has quit IRC
17:25:53  <nielsm> I think it's perfectly acceptable for a game mod to set rules for what's valid playing and what's not, but seeing how much of a sandbox TT games are it's also suggestable that mod authors provide a "free play" mode
17:26:31  <andythenorth> that's not the spec :)
17:26:57  <andythenorth> also we're boxed in on this
17:27:10  <andythenorth> on the one hand it will be 'horrible devs won't implement shunting'
17:27:18  <andythenorth> and if we do, multiple newgrf authors will rage quit
17:27:32  <andythenorth> then it's 'horrible devs forced best contributors out'
17:27:40  <Eddi|zuHause> nielsm: but that's a discussion between the newgrf authors and their users, we're discussing here the appropriate foundations
17:33:28  <andythenorth> I think shunting is probably a no-no currently
17:34:59  *** KouDy has quit IRC
17:35:16  <andythenorth> unless newgrf vehicles are banned from shunting if the flag is not set
17:35:17  <andythenorth> I guess
17:36:32  <planetmaker_> ^^ that is my very suggestion for how to tackle it @andythenorth
17:36:32  <andythenorth> remember the engine pool disaster?
17:36:35  <andythenorth> we shouldn't really have done engine pool
17:36:53  <planetmaker_> because now we have unlimitted vehicles and sets?
17:37:09  <andythenorth> no because it broke sets where authors assumed they were only grf
17:37:18  <andythenorth> I remember it as very painful
17:37:36  <andythenorth> we destroyed years of work remember?
17:37:40  <andythenorth> community split
17:37:53  <planetmaker_> oh, sure. yeah... but... I don't quite remember it as painful. As... it was easy to keep using one newgrf
17:38:12  <andythenorth> but we *allowed* players to choose more than one
17:38:20  <andythenorth> so trains could be mixed up
17:38:27  <andythenorth> even as newgrf author didn't intend
17:38:52  <andythenorth> :P
17:38:54  <planetmaker_> yes... I'm probably more engineer than artist. I consider that great. An artist horrible ;)
17:41:03  <planetmaker_> So yes, it's rather easy to implement it as opt-in which is set globally for a NewGRF
17:41:03  <planetmaker_> and then ... voila
17:41:11  <planetmaker_> most NewGRFs are then likely quickly updated in ...12 months. And the rest is not maintained anymore
17:41:21  <planetmaker_> Or are vapourware :P
17:43:08  <andythenorth> flag does seem safest
17:43:15  <andythenorth> like autorefit
17:43:39  <andythenorth> then ban some behaviours
17:43:59  <planetmaker_> yep. And stops all kind of anger and fears
17:45:32  <Eddi|zuHause> i think that approach is too easy
17:45:57  <planetmaker_> you mean it's too non-traditional and too uncontroversial?
17:47:19  <Eddi|zuHause> no, i mean you're ignoring issues that are perfectly valid
17:47:34  <Eddi|zuHause> just on the grounds that you don't want to think about them
17:47:59  <planetmaker_> uh. such as?
17:50:20  <planetmaker_> Mind that neither andy nor me said that such a newgrf-global flag magically solves all problems. But it solves many social ones in the first place, and many which might result from [sprites not available / not specifically drawn / ...] being taken care of explicitly by the newgrf author
17:50:29  *** planetmaker_ has quit IRC
17:54:59  *** rocky1138 has quit IRC
17:58:47  *** stefino has quit IRC
17:59:17  *** Lejving__ has joined #openttd
17:59:35  *** planetmaker_ has joined #openttd
17:59:40  <planetmaker_> @logs
17:59:40  <DorpsGek> planetmaker_: https://webster.openttdcoop.org/index.php?channel=openttd
18:00:04  *** Arveen2 has joined #openttd
18:00:10  *** HerzogDeXtEr has joined #openttd
18:00:17  *** tokai|noir has joined #openttd
18:00:17  *** ChanServ sets mode: +v tokai|noir
18:00:23  *** Wacko1976_ has quit IRC
18:00:27  *** nielsm is now known as Guest5088
18:00:27  *** Eddi|zuHause has quit IRC
18:00:30  *** berndj has quit IRC
18:00:49  *** guru3 has quit IRC
18:00:59  *** Eddi|zuHause has joined #openttd
18:01:23  *** andythenorth is now known as Guest5092
18:01:36  *** berndj has joined #openttd
18:01:43  *** andythenorth has joined #openttd
18:05:03  *** Guest5088 has quit IRC
18:05:08  *** Guest5092 has quit IRC
18:05:52  *** guru3 has joined #openttd
18:06:08  *** Lejving_ has quit IRC
18:06:13  *** HerzogDeXtEr1 has quit IRC
18:06:28  *** tokai has quit IRC
18:06:28  *** Arveen has quit IRC
18:06:33  <andythenorth> Eddi|zuHause: I think flag is foundation, then the spec needs to do more
18:06:52  <andythenorth> there is no getting around that authors don't want shunting, so need to be able to forbid it
18:07:10  <andythenorth> and the forbidding needs to work for software we can't modify, i.e. existing grfs
18:07:45  <Eddi|zuHause> i don't think that many authors want no shunting at all
18:08:28  <andythenorth> well, we know that some don't
18:08:37  <andythenorth> I didn't mean to imply 'all authors' there
18:08:39  <andythenorth> sorry
18:10:26  <Eddi|zuHause> well, let's look at other examples: when we reworked flipping vehicles in depot, we identified some "trivial" cases where the NewGRF wasn't conflicting, and allowed flipping for those, all the other cases had to implement a special callback to work
18:11:33  <Eddi|zuHause> my aim here would be a similar thing. all (or most of) the "unproblematic" cases should just work with shunting, and for the special cases, give the NewGRF authors the right tools to handle them
18:12:01  <andythenorth> nah depot flip is a flag
18:12:11  <andythenorth> otherwise no flip
18:12:23  <andythenorth> actually we broke newgrf there and annoyed a lot of people
18:12:39  <Eddi|zuHause> no, we broke a thing that never worked properly before either
18:13:00  <andythenorth> not in the eyes of players or authors
18:13:10  <Eddi|zuHause> because the non-8-units long vehicles had to have special offsets depending on whether it was flipped or not
18:13:12  <andythenorth> yes
18:13:15  <andythenorth> it was terrible
18:13:27  <andythenorth> it was the right thing to do
18:13:44  <andythenorth> and the rage was only because there was an existing behaviour
18:13:50  <andythenorth> there's no existing behaviour for shunting
18:15:00  <Eddi|zuHause> i think the shunting operation should be attempted, and if callback results differ between before and after, it should throw an error message and skip the shunting order
18:15:22  <Eddi|zuHause> also, i have no problem with disabling shunting if the engine has wagon override enabled
18:15:40  <Eddi|zuHause> both things have to be communicated with the user
18:16:17  <andythenorth> I think that is all good
18:16:43  <andythenorth> my flag proposal is for newgrf authors who need to explictly ban shunting
18:17:02  <andythenorth> for released newgrfs
18:17:12  <andythenorth> it should be opt-in choice
18:17:27  <Eddi|zuHause> i disagree
18:17:40  <andythenorth> rationale?
18:17:52  <andythenorth> the choice is binary, opt-in, opt-out, I don't miss anything?
18:18:30  <andythenorth> or you propose newgrf author can choose to handle a cb when shunting happens?
18:19:00  <Eddi|zuHause> yes, the NewGRF needs some more details
18:19:12  <andythenorth> yes but already released newgrfs?
18:19:20  <andythenorth> we can't modify what's already out there
18:19:37  <andythenorth> sorry, I just see that as fundamental
18:19:47  <Eddi|zuHause> example: you have two ICE2 unites [head]-[wagon]*n-[steering] + [steering]-[wagon]*n-[head]
18:20:13  <Eddi|zuHause> you would want to allow shunting between two heads, or two steering wagons, or mixed, but not between the wagons
18:20:47  <Eddi|zuHause> or the case where you wouldn't want to put cargo wagons on such a unit
18:20:56  <andythenorth> I think we solve different issues
18:21:15  <andythenorth> I agree with your proposals, but you can't write new newgrf code for released grfs
18:21:19  <andythenorth> they're already shipped
18:21:19  <Eddi|zuHause> i think we have very many issues
18:22:42  <andythenorth> well
18:22:45  *** Thedarkb has joined #openttd
18:22:58  <andythenorth> is the released grfs issue handled by running wagon-attach cb when shunting?
18:23:03  <andythenorth> and respecting the result?
18:23:42  <andythenorth> this is a social problem with authors, not with cb 36
18:23:43  <andythenorth> btw
18:23:50  <andythenorth> cb 36 is different issue
18:24:18  <Eddi|zuHause> yes, but i think "disallow shunting for all old GRFs" is not the right solution
18:24:25  <andythenorth> fundamentally we have to respect "that engine can't run with that wagon" if authors require that
18:24:30  <andythenorth> I wish we didn't, but eh
18:24:34  <andythenorth> cat out of bag
18:25:04  <Eddi|zuHause> i think we can adapt the wagon-attach-callback to run during shunting operations
18:25:26  <Eddi|zuHause> and then refuse the shunting the same way as with the CB36-guard i proposed above
18:25:53  <andythenorth> ok that's 2 issues solved
18:26:11  <Eddi|zuHause> (the wagon-attach callback in itself is flawed as well, as it only asks A to allow B to attach, it doesn't ask B)
18:26:51  <andythenorth> hmm
18:26:59  <andythenorth> I never use it, because, why would you?
18:27:08  <andythenorth> how does it work?
18:27:11  * andythenorth -> spec
18:27:31  <andythenorth> it was made to placate a canadian who massively destructively rage quit in the end anyway
18:27:53  <Eddi|zuHause> both MB and George use it, i think
18:28:24  <andythenorth> pikka did too
18:28:31  <andythenorth> and V I think
18:28:49  <andythenorth> ok so the issue is 'this engine may not haul wagon x'
18:28:50  <andythenorth> fine
18:28:55  <Eddi|zuHause> i would be surprised if Snail doesn't
18:28:56  <andythenorth> just respect the cb
18:29:39  <andythenorth> if carriage A in newgrf B attaches to engine C in newgrf D, eh [shrug]
18:29:47  <Eddi|zuHause> the typical way to circumvent wagon-attach-callback is to use the invisible engine as front engine. because of the before-mentioned "B doesn't get asked" flaw
18:32:26  <andythenorth> ok so
18:32:31  <andythenorth> - attachment check
18:32:35  <andythenorth> - cb36 result validation
18:32:38  <andythenorth> what else?
18:32:43  <Eddi|zuHause> wagon override
18:32:50  <andythenorth> I never understand wagon override :P
18:32:57  <andythenorth> engine specifies liveries?
18:33:39  *** nielsm has joined #openttd
18:33:42  <Eddi|zuHause> original intention was to have T.I.M and AsiaStar livery wagons
18:33:51  <nielsm> huh why did I get disconnected.... oh well
18:33:57  <nielsm> been working on a little thing too: http://0x0.st/s_Eq.png
18:34:19  <Eddi|zuHause> i was also disconnected earlier
18:34:44  *** gelignite has joined #openttd
18:35:04  <andythenorth> o_O
18:36:02  *** Fuco has joined #openttd
18:37:07  <nielsm> and then going from the title screen game to an almost blank 64x64 map: http://0x0.st/s_Ec.png
18:38:01  <Eddi|zuHause> not quite sure how to read that output
18:38:31  <nielsm> long, medium, short term times taken to do various core parts of the game logic
18:38:48  <nielsm> "overall" is based on the time between calls to the main game loop
18:39:30  <nielsm> "gameloop times" is how long it takes to process all the game logic (pathfinding, towns and industry growth, etc)
18:39:49  <nielsm> "drawing times" is how long it takes for the windowing system and blitter to produce the image to put on screen
18:39:58  <nielsm> "video times" is how long it actually takes to put it on screen
18:41:14  *** KouDy has joined #openttd
18:41:58  <nielsm> those screenshots are taken from an unoptimized debug build, so everything is slow
18:42:29  <nielsm> in an optimized x64 build everything is so fast most times just end up as 0.00 ms
18:43:28  <Eddi|zuHause> try one of those old Coop games :p
18:43:46  <nielsm> need to rush for some food now
18:50:47  <snail_UES_> just got in now...
18:51:27  <snail_UES_> I’ve read your discussion above, I’m sorry to say that changing a vehicle length through CB36 is the only alternative to having a huge purchase list :p
18:53:00  <snail_UES_> ideally there should be a callback or something that returns the “original” engine a wagon was attached to when it left the depot
18:53:05  <snail_UES_> that could be cached
18:53:27  <snail_UES_> then, you could allow shunting upon different conditions, depending on what that “original” engine was
18:56:01  <snail_UES_> something similar to the “can attach” callback. There could be a “can shunt”; this would decide which engine IDs could shunt that vehicle
18:56:18  <snail_UES_> and this would work very well if we could identify the “original engine” this wagon left the depot with
18:57:33  <andythenorth> snail_UES_: a huge purchase list is fine btw
18:57:43  <andythenorth> but it's a side issue
18:57:46  <snail_UES_> andythenorth: I beg to differ
18:58:02  <andythenorth> irrespective of how you're using CB36, it has to not break anyway
18:58:18  <snail_UES_> what has not to break?
18:58:39  <andythenorth> length
18:58:41  <andythenorth> etc
18:59:09  <snail_UES_> CB36 is used to change length and you can’t say it’s “wrong"...
18:59:21  <andythenorth> I could solve your issue in the grf, there are only 8 lengths
18:59:27  <andythenorth> you don't need a huge purchase list
18:59:33  <snail_UES_> then, shunting would occur among the cases when length changes
18:59:33  <andythenorth> but that doesn't solve shunting
18:59:51  <snail_UES_> andythenorth: there is no “issue” in my grf
19:00:07  <andythenorth> poor choice of words
19:00:14  <snail_UES_> it’s just the concept of multiple similar vehicles cluttering the purchase list that makes no sense...
19:00:17  <andythenorth> I don't mean 'bad issue'
19:00:22  <andythenorth> I just mean 'you chose a route'
19:00:47  <andythenorth> I could spend 6 weeks persuading you to change it, but still doesn't solve shunting :P
19:01:05  <andythenorth> I think Eddi|zuHause solved the length issue anyway
19:01:08  <snail_UES_> I think it’s more of a philosophical thing
19:01:15  <andythenorth> yes
19:01:35  <snail_UES_> I’ve received feedback from my playtesters that they prefer automatic length change rather than a silly purchase list
19:01:39  <andythenorth> running the cb and refusing to shunt if values change is probably a solution
19:01:58  <andythenorth> Eddi|zuHause convinced me about that one
19:02:22  <andythenorth> and also running current 'can attach' cb as well
19:02:43  <andythenorth> I think those 2 solve most of the newgrf problems
19:03:29  * andythenorth -> gtg :)
19:03:33  *** andythenorth has quit IRC
19:24:33  <snail_UES_> just posted my proposal on the forum
19:30:39  *** tokai has joined #openttd
19:30:39  *** ChanServ sets mode: +v tokai
19:34:04  *** KouDy has quit IRC
19:37:33  *** tokai|noir has quit IRC
19:38:51  *** glx has joined #openttd
19:38:52  *** ChanServ sets mode: +v glx
19:52:10  *** KouDy has joined #openttd
20:21:09  <Wolf01> https://www.flickr.com/photos/140731612@N05/41744646241/in/pool-1120587@N22 seem small
20:29:56  <Arveen2> looking at the tiles it's rather big
20:40:53  *** Thedarkb has quit IRC
20:45:36  *** Thedarkb has joined #openttd
20:58:56  <nielsm> http://0x0.st/s_6N.png
21:14:17  *** supermop has joined #openttd
21:31:03  <nielsm> the translatable strings system doesn't have a way to display float values, does it?
21:40:44  *** gelignite has quit IRC
21:44:36  <frosch123> there is a fixed-point float number for the train length
21:46:01  *** planetmaker_ has quit IRC
21:46:12  <frosch123> nielsm: {DECIMAL}
21:47:47  <nielsm> ah
21:47:58  <nielsm> will fix my code to use that then
21:53:34  *** KouDy has quit IRC
21:58:47  <nielsm> made a PR of it now
21:59:18  *** Wormnest_ has joined #openttd
22:06:18  *** Wormnest has quit IRC
22:11:44  *** KouDy has joined #openttd
22:26:28  *** GT has joined #openttd
22:38:42  <Wolf01> 'night
22:38:44  *** Wolf01 has quit IRC
23:12:48  *** nielsm has quit IRC
23:16:46  *** supermop has quit IRC
23:21:38  *** Wormnest_ has quit IRC
23:27:03  *** Fuco has quit IRC
23:28:37  *** Thedarkb1-X40 has joined #openttd
23:28:50  *** Thedarkb1 has joined #openttd
23:35:13  *** beno__ has quit IRC
23:35:13  *** Thedarkb has quit IRC
23:45:51  *** GT has left #openttd
23:57:53  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk