IRC logs for #openttd on OFTC at 2018-06-09
⏴ go to previous day
00:19:55 *** chomwitt has joined #openttd
00:39:16 *** CompuDesktop has joined #openttd
00:51:47 *** rocky1138 has joined #openttd
01:02:25 <vj> when is the 1000 buildings sky scraper going to be finished? i would be waiting for it.
01:03:51 <vj> can i be the member of this group?
01:03:52 <ST2> vj: if using the propper newgrf, around 1895 ^^
01:06:06 <ST2> vj: questions must give more info, vanilla, any newgrf's used, which ones, start year, current game year, etc etc
01:07:40 <vj> no really i want to know. this game is really intresting
01:07:58 <vj> it is competeing many games
01:08:44 <ST2> from there you'll know most of the game
01:08:53 <ST2> the rest is .... playing :D
01:21:25 <m1cr0man> Hi all, quick question. If when restart_game_year is set and triggered, is the map regenerated with a new seed or will it generate the same map?
01:23:03 <glx> need to check the source to answer I think
01:23:42 <m1cr0man> ok. I'm assuming it regenerates the world but doesn't change the seed because that's a config option - thinking about writing a script to run the command to change the seed every so often :P
01:25:12 <glx> I think it's the same as typing restart in the console
01:25:57 <m1cr0man> never done that either actually - does regen the seed and map?
01:26:20 <m1cr0man> uh...does that* stg I shouldn't be asking questions this late in the evening...
01:28:39 <glx> when the restart date is reached it does StartNewGameWithoutGUI(GENERATE_NEW_SEED);
01:29:01 <m1cr0man> Aw perfect :D thanks for looking that up for me
01:32:45 <glx> restart command keeps the seed while newgame command use a new seed
02:00:03 *** Thedarkb has joined #openttd
03:20:23 *** supermop has joined #openttd
04:49:51 *** muffindrake2 has joined #openttd
05:04:45 *** ToffeeYogurtPots has quit IRC
05:17:54 *** supermop_work has joined #openttd
05:20:55 *** supermop_work_ has quit IRC
06:48:54 *** Progman has joined #openttd
08:14:09 *** andythenorth has joined #openttd
08:42:28 *** HerzogDeXtEr has joined #openttd
10:00:26 *** sla_ro|master has joined #openttd
10:27:55 *** planetmaker_ has joined #openttd
10:53:48 *** Wacko1976 has joined #openttd
11:17:50 *** Wacko1976_ has joined #openttd
11:54:44 *** Wormnest has joined #openttd
12:20:40 *** synchris has joined #openttd
12:44:46 *** frosch123 has joined #openttd
12:52:42 *** Thedarkb has joined #openttd
13:32:17 *** Thedarkb has joined #openttd
13:39:28 *** supermop has joined #openttd
13:47:12 *** ChanServ sets mode: +v tokai
14:17:54 *** Thedarkb has joined #openttd
14:36:13 *** supermop has joined #openttd
16:05:40 *** HerzogDeXtEr1 has joined #openttd
17:35:56 *** snail_UES_ has joined #openttd
17:50:45 *** andythenorth has joined #openttd
17:54:00 <andythenorth> in retrospect, changing length on cb36 is bonkers
17:54:15 <andythenorth> if any property should be immutable, it's vehicle length
17:56:16 *** virtualrandomnumber has joined #openttd
18:01:11 <nielsm> isn't it used for "generic multiple unit cars" and the like?
18:01:30 <nielsm> e.g. in the 2cc in NML train set?
18:03:14 <nielsm> (personally I'd rather have only fixed-length train sets, especially for MUs based on real-world material)
18:05:57 *** muffindrake has joined #openttd
18:07:43 *** rocky1138 has joined #openttd
18:12:41 <planetmaker_> CB36 length changes are used in several trainsets. And I consider it unlikely that it changed in the last 12 months ;)
18:14:38 <andythenorth> it's a legacy of only 128 IDs or whatever in patch
18:19:08 <nielsm> it's also a tool to keep the list of purchasable wagon types manageable from the player's perspective
18: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
18:21:47 *** stefino has joined #openttd
18: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 ?
18:24:31 <nielsm> no, refit can't change the number of cars in a train
18:26:24 <stefino> really? have a feeling that it is possible. So no way...have to build it part by part
18:31:11 <planetmaker_> stefino, well. Technically that's not possible. But actually a newgrf developer can make it so
18:31:32 <planetmaker_> by introducing invisible wagons. And changing length upon refit
18: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.
18:33:40 <planetmaker_> stefino, *that* is the LOT easier way to implement that, yes
18: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
18:36:45 *** Thedarkb has joined #openttd
18:38:17 <andythenorth> you can change look based on position, easily
18:38:57 <andythenorth> nielsm: refitting the generic cars doesn't help the shunting situation much
18: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
18:39:25 <andythenorth> the whole 'cannot attach' situation needs to die for shunting
18:40:32 <stefino> so the 3rd option is to code all sets individualy
18:41:09 <stefino> it takes the same number of purchase list lines
18: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
18:42:23 <andythenorth> eddi suggested similar
18:42:34 <andythenorth> but that doesn't help the newgrf spec much
18: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
18:42:49 <andythenorth> unless it's sandboxed, and changes the behaviour of some vars
18:43:20 <andythenorth> if we sandbox a 'consist' and vehicles can't read outside it, it's fine
18:43:26 <andythenorth> except it breaks grfs
18:44:07 <andythenorth> due to history, grfs are fundamentally in conflict with shunting
18:44:23 <andythenorth> grf world has taken the view that grf author controls the train, not the player
18:49:10 <planetmaker_> oh, is shunting again a thing?
18:49:21 <Wolf01> Shunting is always a thing
18: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
18: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)
18:51:26 <nielsm> and only cars with compatible couplers can attach
18:51:36 <nielsm> and a coupler type can be hard or soft
18:52:11 <nielsm> or you could even allow coupler types to specify how long it takes to perform the couple/decouple operation
18: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)
18: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?
18:54:51 <andythenorth> nielsm: nah, I think you solve wrong problem
18:55:01 <andythenorth> what problem do you try to solve? :)
18:56:04 <planetmaker_> When I ponder(ed) shunting I considered yet another newgrf flag, set at global level by the trainset: [x] allow shunting
18:56:21 <nielsm> I'm just offering a solution in search of a problem!
18: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)
18:57:40 <andythenorth> planetmaker: I think it has to be something like that
18:58:00 <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
18:58:17 <andythenorth> then 'can attach' needs extending to handle shunting
18:58:22 <andythenorth> with messages for player
18:58:29 <andythenorth> also it needs to account for conditional orders
18:59:54 <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
19:01:00 <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
19: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
19:02:54 <planetmaker_> ^^ I don't think you want to prevent players doing that
19: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
19:03:41 <planetmaker_> so every realism-based player can play happily. And everyone who doesn't care, can still do what they like
19:04:05 <nielsm> then you make a mistake with your orders and end up "why the heck is train EMU hauling around the coal???"
19:04:28 <nielsm> (and "what's that EMU doing at the coal mine?")
19:04:32 <planetmaker_> so fix that mistake and you can continue to play happily
19:05:43 <planetmaker_> basically you ask for the game to make decisions you like for everyone - irrespective if it suits them or not :)
19: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?
19: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
19:06:56 <planetmaker_> But at the same time I could build my sci-fi universe with it.
19:09:48 <andythenorth> nielsm: yes incompatible trains should stop
19:10:07 <andythenorth> like when they can't find a path and get stuck in a block
19: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
19:16:27 <andythenorth> that needs extending for shunting
19:19:58 <andythenorth> the key objective is to ensure that trains remain built as newgrf authors want
19:20:11 <andythenorth> otherwise it's a spec violation
19:20:23 <andythenorth> it's not up to the player to compose trains
19:21:00 <Eddi|zuHause> well it is, but when the newgrf author wants to put restrictions on it, we should respect those
19:21:21 <andythenorth> I would be trolling, but I'm not
19:21:31 <Eddi|zuHause> sometimes more restrictions make for better gameplay
19:21:33 <andythenorth> historical fact is that newgrf spec exists to let newgrf authors control player behaviour
19:21:44 <andythenorth> unless we bump version
19:23:03 *** virtualrandomnumber has quit IRC
19: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
19:26:31 <andythenorth> that's not the spec :)
19:26:57 <andythenorth> also we're boxed in on this
19:27:10 <andythenorth> on the one hand it will be 'horrible devs won't implement shunting'
19:27:18 <andythenorth> and if we do, multiple newgrf authors will rage quit
19:27:32 <andythenorth> then it's 'horrible devs forced best contributors out'
19:27:40 <Eddi|zuHause> nielsm: but that's a discussion between the newgrf authors and their users, we're discussing here the appropriate foundations
19:33:28 <andythenorth> I think shunting is probably a no-no currently
19:35:16 <andythenorth> unless newgrf vehicles are banned from shunting if the flag is not set
19:36:01 <planetmaker_> ^^ that is my very suggestion for how to tackle it @andythenorth
19:36:19 <andythenorth> remember the engine pool disaster?
19:36:35 <andythenorth> we shouldn't really have done engine pool
19:36:53 <planetmaker_> because now we have unlimitted vehicles and sets?
19:37:09 <andythenorth> no because it broke sets where authors assumed they were only grf
19:37:18 <andythenorth> I remember it as very painful
19:37:36 <andythenorth> we destroyed years of work remember?
19:37:53 <planetmaker_> oh, sure. yeah... but... I don't quite remember it as painful. As... it was easy to keep using one newgrf
19:38:12 <andythenorth> but we *allowed* players to choose more than one
19:38:20 <andythenorth> so trains could be mixed up
19:38:27 <andythenorth> even as newgrf author didn't intend
19:38:54 <planetmaker_> yes... I'm probably more engineer than artist. I consider that great. An artist horrible ;)
19:40:36 <planetmaker_> So yes, it's rather easy to implement it as opt-in which is set globally for a NewGRF
19:40:40 <planetmaker_> and then ... voila
19:41:11 <planetmaker_> most NewGRFs are then likely quickly updated in ...12 months. And the rest is not maintained anymore
19:41:21 <planetmaker_> Or are vapourware :P
19:43:08 <andythenorth> flag does seem safest
19:43:39 <andythenorth> then ban some behaviours
19:43:59 <planetmaker_> yep. And stops all kind of anger and fears
19:45:32 <Eddi|zuHause> i think that approach is too easy
19:45:57 <planetmaker_> you mean it's too non-traditional and too uncontroversial?
19:47:19 <Eddi|zuHause> no, i mean you're ignoring issues that are perfectly valid
19:47:34 <Eddi|zuHause> just on the grounds that you don't want to think about them
19: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
19:59:17 *** Lejving__ has joined #openttd
19:59:35 *** planetmaker_ has joined #openttd
20:00:04 *** Arveen2 has joined #openttd
20:00:10 *** HerzogDeXtEr has joined #openttd
20:00:17 *** tokai|noir has joined #openttd
20:00:17 *** ChanServ sets mode: +v tokai|noir
20:00:27 *** nielsm is now known as Guest5088
20:00:59 *** Eddi|zuHause has joined #openttd
20:01:23 *** andythenorth is now known as Guest5092
20:01:43 *** andythenorth has joined #openttd
20:06:33 <andythenorth> Eddi|zuHause: I think flag is foundation, then the spec needs to do more
20:06:52 <andythenorth> there is no getting around that authors don't want shunting, so need to be able to forbid it
20:07:10 <andythenorth> and the forbidding needs to work for software we can't modify, i.e. existing grfs
20:07:45 <Eddi|zuHause> i don't think that many authors want no shunting at all
20:08:28 <andythenorth> well, we know that some don't
20:08:37 <andythenorth> I didn't mean to imply 'all authors' there
20: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
20: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
20:12:01 <andythenorth> nah depot flip is a flag
20:12:11 <andythenorth> otherwise no flip
20:12:23 <andythenorth> actually we broke newgrf there and annoyed a lot of people
20:12:39 <Eddi|zuHause> no, we broke a thing that never worked properly before either
20:13:00 <andythenorth> not in the eyes of players or authors
20:13:10 <Eddi|zuHause> because the non-8-units long vehicles had to have special offsets depending on whether it was flipped or not
20:13:27 <andythenorth> it was the right thing to do
20:13:44 <andythenorth> and the rage was only because there was an existing behaviour
20:13:50 <andythenorth> there's no existing behaviour for shunting
20: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
20:15:22 <Eddi|zuHause> also, i have no problem with disabling shunting if the engine has wagon override enabled
20:15:40 <Eddi|zuHause> both things have to be communicated with the user
20:16:17 <andythenorth> I think that is all good
20:16:43 <andythenorth> my flag proposal is for newgrf authors who need to explictly ban shunting
20:17:02 <andythenorth> for released newgrfs
20:17:12 <andythenorth> it should be opt-in choice
20:17:52 <andythenorth> the choice is binary, opt-in, opt-out, I don't miss anything?
20:18:30 <andythenorth> or you propose newgrf author can choose to handle a cb when shunting happens?
20:19:00 <Eddi|zuHause> yes, the NewGRF needs some more details
20:19:12 <andythenorth> yes but already released newgrfs?
20:19:20 <andythenorth> we can't modify what's already out there
20:19:37 <andythenorth> sorry, I just see that as fundamental
20:19:47 <Eddi|zuHause> example: you have two ICE2 unites [head]-[wagon]*n-[steering] + [steering]-[wagon]*n-[head]
20:20:13 <Eddi|zuHause> you would want to allow shunting between two heads, or two steering wagons, or mixed, but not between the wagons
20:20:47 <Eddi|zuHause> or the case where you wouldn't want to put cargo wagons on such a unit
20:20:56 <andythenorth> I think we solve different issues
20:21:15 <andythenorth> I agree with your proposals, but you can't write new newgrf code for released grfs
20:21:19 <andythenorth> they're already shipped
20:21:19 <Eddi|zuHause> i think we have very many issues
20:22:45 *** Thedarkb has joined #openttd
20:22:58 <andythenorth> is the released grfs issue handled by running wagon-attach cb when shunting?
20:23:03 <andythenorth> and respecting the result?
20:23:42 <andythenorth> this is a social problem with authors, not with cb 36
20:23:50 <andythenorth> cb 36 is different issue
20:24:18 <Eddi|zuHause> yes, but i think "disallow shunting for all old GRFs" is not the right solution
20:24:25 <andythenorth> fundamentally we have to respect "that engine can't run with that wagon" if authors require that
20:24:30 <andythenorth> I wish we didn't, but eh
20:25:04 <Eddi|zuHause> i think we can adapt the wagon-attach-callback to run during shunting operations
20:25:26 <Eddi|zuHause> and then refuse the shunting the same way as with the CB36-guard i proposed above
20:25:53 <andythenorth> ok that's 2 issues solved
20: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)
20:26:59 <andythenorth> I never use it, because, why would you?
20:27:07 <andythenorth> how does it work?
20:27:31 <andythenorth> it was made to placate a canadian who massively destructively rage quit in the end anyway
20:27:53 <Eddi|zuHause> both MB and George use it, i think
20:28:49 <andythenorth> ok so the issue is 'this engine may not haul wagon x'
20:28:55 <Eddi|zuHause> i would be surprised if Snail doesn't
20:28:56 <andythenorth> just respect the cb
20:29:39 <andythenorth> if carriage A in newgrf B attaches to engine C in newgrf D, eh [shrug]
20: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
20:32:31 <andythenorth> - attachment check
20:32:35 <andythenorth> - cb36 result validation
20:32:50 <andythenorth> I never understand wagon override :P
20:32:57 <andythenorth> engine specifies liveries?
20:33:42 <Eddi|zuHause> original intention was to have T.I.M and AsiaStar livery wagons
20:33:51 <nielsm> huh why did I get disconnected.... oh well
20:34:19 <Eddi|zuHause> i was also disconnected earlier
20:34:44 *** gelignite has joined #openttd
20:38:01 <Eddi|zuHause> not quite sure how to read that output
20:38:31 <nielsm> long, medium, short term times taken to do various core parts of the game logic
20:38:48 <nielsm> "overall" is based on the time between calls to the main game loop
20:39:30 <nielsm> "gameloop times" is how long it takes to process all the game logic (pathfinding, towns and industry growth, etc)
20:39:49 <nielsm> "drawing times" is how long it takes for the windowing system and blitter to produce the image to put on screen
20:39:58 <nielsm> "video times" is how long it actually takes to put it on screen
20:41:58 <nielsm> those screenshots are taken from an unoptimized debug build, so everything is slow
20:42:29 <nielsm> in an optimized x64 build everything is so fast most times just end up as 0.00 ms
20:43:28 <Eddi|zuHause> try one of those old Coop games :p
20:43:46 <nielsm> need to rush for some food now
20:50:47 <snail_UES_> just got in now...
20: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
20: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
20:53:05 <snail_UES_> that could be cached
20:53:27 <snail_UES_> then, you could allow shunting upon different conditions, depending on what that “original” engine was
20: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
20:56:18 <snail_UES_> and this would work very well if we could identify the “original engine” this wagon left the depot with
20:57:33 <andythenorth> snail_UES_: a huge purchase list is fine btw
20:57:43 <andythenorth> but it's a side issue
20:57:46 <snail_UES_> andythenorth: I beg to differ
20:58:02 <andythenorth> irrespective of how you're using CB36, it has to not break anyway
20:58:18 <snail_UES_> what has not to break?
20:59:09 <snail_UES_> CB36 is used to change length and you can’t say it’s “wrong"...
20:59:21 <andythenorth> I could solve your issue in the grf, there are only 8 lengths
20:59:27 <andythenorth> you don't need a huge purchase list
20:59:33 <snail_UES_> then, shunting would occur among the cases when length changes
20:59:33 <andythenorth> but that doesn't solve shunting
20:59:51 <snail_UES_> andythenorth: there is no “issue” in my grf
21:00:07 <andythenorth> poor choice of words
21:00:14 <snail_UES_> it’s just the concept of multiple similar vehicles cluttering the purchase list that makes no sense...
21:00:17 <andythenorth> I don't mean 'bad issue'
21:00:22 <andythenorth> I just mean 'you chose a route'
21:00:47 <andythenorth> I could spend 6 weeks persuading you to change it, but still doesn't solve shunting :P
21:01:05 <andythenorth> I think Eddi|zuHause solved the length issue anyway
21:01:08 <snail_UES_> I think it’s more of a philosophical thing
21:01:35 <snail_UES_> I’ve received feedback from my playtesters that they prefer automatic length change rather than a silly purchase list
21:01:39 <andythenorth> running the cb and refusing to shunt if values change is probably a solution
21:01:58 <andythenorth> Eddi|zuHause convinced me about that one
21:02:22 <andythenorth> and also running current 'can attach' cb as well
21:02:43 <andythenorth> I think those 2 solve most of the newgrf problems
21:24:33 <snail_UES_> just posted my proposal on the forum
21:30:39 *** ChanServ sets mode: +v tokai
22:29:56 <Arveen2> looking at the tiles it's rather big
22:45:36 *** Thedarkb has joined #openttd
23:14:17 *** supermop has joined #openttd
23:31:03 <nielsm> the translatable strings system doesn't have a way to display float values, does it?
23:44:36 <frosch123> there is a fixed-point float number for the train length
23:47:58 <nielsm> will fix my code to use that then
23:59:18 *** Wormnest_ has joined #openttd
continue to next day ⏵
