IRC logs for #openttd.dev on OFTC at 2012-09-25
⏴ go to previous day
07:32:02 *** andythenorth has joined #openttd.dev
07:32:02 *** ChanServ sets mode: +v andythenorth
10:06:44 *** andythenorth has left #openttd.dev
15:27:35 *** FLHerne has joined #openttd.dev
15:28:46 *** FLHerne has joined #openttd.dev
17:20:46 *** frosch123 has joined #openttd.dev
17:20:46 *** ChanServ sets mode: +v frosch123
17:56:18 *** Alberth has joined #openttd.dev
17:56:18 *** ChanServ sets mode: +v Alberth
18:49:32 <frosch123> i still like the "keep order of introduction and extroduction"-change the most
18:49:52 <frosch123> don't think adding dependencies as for railtypes would make it easier
18:53:11 <Alberth> perhaps we should always keep stuff introduced at the same date together
18:53:42 <frosch123> yeah, that's what i mean
18:53:56 <frosch123> setting the same introdate would also cause the same randomisation
18:56:20 <Yexo> that should be easy enough to implement
18:56:39 <Alberth> I agree, the EMU proposal seems very complicated to me, even at a birds-eye view
18:56:41 <frosch123> i am not sure how to handle extroduction :p
18:57:16 <frosch123> i guess if introdate and lifetime are set to the same value, both intro and extro date should be the same
18:57:18 <Yexo> it could make sense if an engine is available even if you can't buy any new wagons for it, just to replace existing engines
18:57:20 <frosch123> but that is about the only case :p
18:57:37 <Yexo> other way around can be explained the same way: possible to add some new wagons to an existing engine, but not buy new engines
18:58:47 <Yexo> what would the effect be on trying out new engines?
18:59:09 <Yexo> basically you get one engine/wagon a year before the introduction date, but it's useless if you mess a wagon you need for the engine
19:01:51 <frosch123> i have no idea what you mean :)
19:03:09 <frosch123> are you referring to aligning the intro of one engine with the extro of another one?
19:03:14 <frosch123> i don't think that is needed
19:03:19 <frosch123> you always want some overlap
19:04:04 <Yexo> wasn't the whole problem that people wanted to introduce an engine and a matching wagon at exactly the same time?
19:04:17 <Yexo> since neither of the two would be useful without the other?
19:06:25 <Alberth> wouldn't you have the same introduction date then?
19:06:50 <Alberth> and since same introduction date sticks together, it works?
19:09:09 <Yexo> yes, but sometimes you get an offer to preview a certain vehicle, you basically get it one year earlier
19:09:20 <Yexo> if we don't change anything to that the vehicle wouldn't be useful in the preview year
19:09:42 <frosch123> ah, preview makes it more complicated :s
19:10:08 <frosch123> would mean previewing one means previewing all
19:10:23 <Alberth> and that problem does not exist now?
19:10:54 <Yexo> but if we want a solution for it we need to think it through properly and not leave part of the problem behind
19:11:30 <frosch123> preview might not work so nice via some implicit rule like "same intro date"
19:12:03 <frosch123> so, maybe we need indeed some property to define engines/vehicles having the same intro and or same extro date
19:12:40 <frosch123> just some a0 property with a list of engine ids
19:13:35 <frosch123> ottd would enforce transitivity if the property is set for different engines
19:14:25 <Yexo> one property with a list or a property that can be specified multiple times?
19:14:52 <frosch123> do we need some kind of resetting of the property?
19:15:01 <frosch123> or any other fancy stuff with addon-grfs?
19:16:03 <frosch123> or maybe something easier? just two properties "copy intro date from engine" and "copy extro date from engine"?
19:16:03 <Yexo> I don't think reset is needed
19:16:15 <frosch123> so you have to set intro and lifetime for one engine
19:16:19 <frosch123> and the copy stuff for all others?
19:16:30 <Yexo> hmm, I like that idea :)
19:16:44 <frosch123> (copy stuff would overrule intro dates, if the engine is valid)
19:17:12 <Yexo> why not last property stays? That way you could overrule the copy stuff with a new intro date in an addon newgrf
19:17:35 <frosch123> what to do in case of circles? :p
19:19:48 <frosch123> do we want to allow c copies from b, b copies from a?
19:20:02 <frosch123> or should we enforce: only copy from stuff which does not copy?
19:20:42 <Yexo> the latter is much easier to code, and I don't see a good reason to allow copies from a to b to c
20:19:17 <frosch123> begin/middle/end is hard to draw an icon for
20:19:32 <frosch123> esp. if it shall be rtl-neutral
20:25:00 *** maceex has joined #openttd.dev
20:25:15 *** maceex has left #openttd.dev
20:27:00 <Alberth> I like the attempt though; perhaps if you start horizontally (as the direction the train comes from)?
20:27:00 <Alberth> We could have icons for LTR and RTL languages
20:27:44 <frosch123> yeah, we have that for some icons
20:27:49 <frosch123> but it always means more work :)
20:28:01 <frosch123> maybe we can also switch begin/end for rtl
20:32:38 <Alberth> hmm, newgrf vehicle parent scope is again a parent :)
20:40:46 *** Alberth has left #openttd.dev
20:43:49 *** SmatZ has joined #openttd.dev
20:43:49 *** ChanServ sets mode: +v SmatZ
20:46:37 *** Supercheese has joined #openttd.dev
22:15:28 *** Hirundo has joined #openttd.dev
22:47:24 *** Supercheese has left #openttd.dev
continue to next day ⏵