IRC logs for #openttd on OFTC at 2013-05-09
⏴ go to previous day
02:07:42 *** Extrems has joined #openttd
02:13:15 *** tokai|mdlx has joined #openttd
02:28:06 *** Biolunar__ has joined #openttd
03:20:30 *** zeknurn` has joined #openttd
03:22:45 *** zeknurn` is now known as zeknurn
03:39:47 *** Flygon__ has joined #openttd
03:43:46 *** LordPixaII has joined #openttd
04:53:17 *** parkette_ has joined #openttd
04:56:15 *** Eddi|zuHause has joined #openttd
04:59:00 *** parkette_ is now known as parkette
05:33:03 *** sla_ro|master has joined #openttd
05:36:55 *** zeknurn` has joined #openttd
05:43:05 *** zeknurn` is now known as zeknurn
06:26:45 *** valhallasw has joined #openttd
06:28:33 *** oskari89 has joined #openttd
06:35:30 *** Flygon_ has joined #openttd
06:37:01 *** |Jeroen| has joined #openttd
07:24:37 *** George is now known as Guest4763
07:43:29 *** Alberth has joined #openttd
07:43:29 *** ChanServ sets mode: +o Alberth
07:44:27 *** Flygon__ has joined #openttd
07:49:50 *** Pensacola has joined #openttd
08:21:05 <planetmaker> I should probably not advertize that, though
08:22:28 *** Progman has joined #openttd
08:29:56 <juzza1> i really feel that should be in NML even though it's not ideally implemented
08:30:23 <planetmaker> yes, it should be there. But I think better implemented :D
08:38:19 <Alberth> I somewhat wonder how the the translation step is that nml makes
08:41:35 <V453000> around 90 centimeters
08:41:40 *** |Jeroen| has joined #openttd
08:42:50 <Alberth> it's a lot of code, but not difficult at all
08:43:39 <Alberth> the mapping quite straightforward
08:44:04 * Alberth seems to be forgetting crucial words today in sentences today :(
08:45:44 *** Rikests has joined #openttd
08:46:02 <planetmaker> uh... big in what sense, Alberth ?
08:47:22 <Alberth> amount of transformation I guess, ie is there a sort-of simple mapping from input to output?
08:47:57 <Rikests> Hey, which cargo distrubution patch is the best atm?
08:48:31 <Alberth> YACD is the best, CargoD?st is actually working on anything recent, and good too
08:49:35 <planetmaker> Alberth, so your question is why NML does need to make so much fuss about strings, basically?
08:49:57 <Alberth> no, more about entire NML
08:50:32 <Alberth> ie how does a "feature"(??) map to NFO primitives? one-to-one?
08:50:37 <planetmaker> I guess I'm slow and I didn't follow your mental step size yet :-)
08:51:03 <Alberth> it's equally possible I don't explain properly :)
08:51:24 <Alberth> Basically I was wondering what would happen if you take the RCDgen approach to nml
08:51:57 <Alberth> ie rewrite it all in C++
08:52:14 <planetmaker> it likely would become a lot faster :D
08:52:43 * Alberth adds sufficiently many "sleep(1);" statements in the code :)
08:52:45 <Rikests> what What is the difference between YACD and cargodist?
08:53:28 <Alberth> rcdgen is mostly just 1-to-1, with expression simplification
08:54:24 <planetmaker> Rikests, yacd sets destinations on cargo generation, whether reachable or not. While cargodist distributes cargo to available destinations
08:54:30 <Alberth> obviously it makes life easier by counting things you enter in the input, and filling in such numbers, etc
08:55:21 <Alberth> Rikests: that means with YACD you also get cargo that wants to go elsewhere than what your network provides
08:55:37 <Rikests> Ok, than YACD is more challenging.
08:57:28 <planetmaker> Alberth, so, that converter you wrote, basically is FreeRCT's NML compiler, yes?
08:57:53 <planetmaker> and you wonder about its differences to NML and the reasons for them (if any)?
08:58:07 <Alberth> yes, except I also define the destination :)
08:58:31 *** George is now known as Guest4770
08:58:48 <Alberth> the CSTR definition and its TRCK definition is also mine
08:59:13 <Alberth> and I don't have history to worry about :)
08:59:16 <planetmaker> yes, sure. You designed and wrote all parts. Programme, specs, etc
09:00:05 <Alberth> planetmaker: and I wonder whether you can sort-of write the same kind of conversion program, and how difficult it would be
09:00:52 <Alberth> the latter is heavily influenced by how much trickery NML does in its conversion to NFO
09:01:26 <Alberth> hence my question how nml primitives relate to nfo primitives
09:01:35 <planetmaker> many things in nfo / nml are mapping stuff 1:1 sort-of. With conversions in between as needed
09:01:51 <planetmaker> property blocks, sprite blocks, sprite layouts, they all have nfo equivalents
09:02:00 <planetmaker> switch statements
09:02:57 <planetmaker> there's much abstraction on the expression level though. Lot of magic with temp variables which the NML user doesn't see at all
09:03:42 <planetmaker> also variables are not 1:1 mapped necessarily to nfo variables, but could be modified parts of them (like inverted bit 5 of variable XY)
09:04:23 <Alberth> so it does advanced code generation for expressions
09:04:31 <planetmaker> very much so, yes
09:05:41 <planetmaker> that's basically the biggest advantage of NML over NFO
09:06:19 <Alberth> that's mostly local I guess? ie I write something simple in NML, and it generates a shit-load of NFO code to compute its value at that point
09:07:12 <Alberth> nice, that would mean from a code generation point of view it's not that complicated
09:07:48 <planetmaker> and that's simple stuff
09:08:44 <planetmaker> one of the problems NML also (partially) solves is that it abstracts away differences between different features (train, road vehicle, airports,...)
09:09:05 <planetmaker> by making them work the same way, while the underlaying NFO works (slightly) different
09:09:38 <planetmaker> i.e. speed is given in NML in units of your choice. While NFO has different, arbitrary units for each feature a different one
09:09:42 <Alberth> those assignments look very doable
09:11:34 <Alberth> very useful for the user, from a program point of view very easy to do
09:12:57 <Alberth> the main benefit is probably actually readable input source, instead of numbers with heaps of comments :p
09:13:38 <planetmaker> that as well. But the expression and temporary and permanent variable storage handling really is, too.
09:14:49 <Alberth> I can imagine, assembly-level expression operations tend to be hard to read and understand
09:16:34 <planetmaker> I'm not exactly sure how the action6 translates into this: values given as parameter.
09:16:46 <planetmaker> That works somewhat differently in NFO than in NML
09:17:08 <planetmaker> in nfo you first write the statement. And the next statement then is told to modify single bytes in the previous one. Depending on a parameter
09:17:18 <Alberth> action 6 is a weird operator
09:18:08 <Alberth> self-modifying code is something of the '80s :)
09:18:12 <planetmaker> I think in many cases here, the devil is in the detail
09:18:54 <Alberth> unfortunately, it always is
09:19:32 <planetmaker> there have been thoughts to (re-)implement NML in C/C++. Mainly for speed reasons
09:20:18 <Alberth> yeah, I am just not sure it's the right direction
09:20:41 <planetmaker> it's LOADS of work. Without any short and possibly neither mid-term benefit
09:21:01 <Alberth> if you implement a linker at NFO level (or below it), you can do partial compilation, which goes a lot further
09:21:35 <Alberth> and it allow leverage of the existing NML compiler
09:21:51 <planetmaker> it basically suffices to write the NFO for the parts. And throw grfcodec on them when the parts are properly ordered
09:22:42 <planetmaker> difficulty is to get right the numbering of items and switch blocks (or rather the nfo equivalent)
09:23:31 <Alberth> afaik, you need a notion of "defining" and "using" between parts
09:24:25 <Alberth> where "defining" probably should assign a number so all uses can refer to it
09:25:00 <Alberth> which boils down to just insterting the same number at several places in the byte stream
09:25:22 <Alberth> and ordering the "define" before the "use" parts :p
09:25:26 <planetmaker> yes. But that needs be done last before actually compiling. In order to avoid conflicts
09:26:06 <planetmaker> so what would need doing basically is NML to output a somewhat pseudo-nfo where action0 IDs and action2 IDs are not yet assigned
09:26:28 <planetmaker> and a numbering step which then converts all these to the actual numbers so that grfcodec can eat it
09:26:52 <planetmaker> an NFOrenum XXL or so ;-)
09:27:01 <planetmaker> with multi-file support
09:27:42 <Alberth> although I am not sure you want grfcodec at the end, I would generate a byte stream (sprite stream) with 'holes' in it :)
09:28:20 <Alberth> so it becomes just concatenating the sprites after each other, and filling in the holes
09:28:33 <planetmaker> what are the holes?
09:29:03 <Alberth> numbers that need to be filled in, ie the IDs
09:29:41 <planetmaker> yes. grfcodec only comes into play after that is done.
09:30:59 <Alberth> my alternative view is that grfcodec (or NML) generates sprite streams with holes, and a linker program than puts the stream in the proper order, and filling of holes
09:31:43 <Alberth> ie just like gcc -o program *.o instead of gcc -o program *.c
09:31:53 <planetmaker> hm, yes. possibly. If it's an NML linker it could (re-use) the sprite cache NML already has
09:32:03 <planetmaker> thus would boil down to splitting NML compiler and linker
09:32:35 <Alberth> there are no sprites any more at that level, just a long sequence of bytes
09:32:47 <Alberth> ie real sprites are already encoded into bytes
09:33:11 <planetmaker> nml's sprite cache is just that, I think
09:33:40 <Alberth> it caches encoded sprite files afaik
09:34:19 <Alberth> my "sprite stream" are sprites as in NFO, ie 1 line NFO == 1 sprite in the stream
09:34:22 <planetmaker> yes. So that it can insert them 1:1 into the grf when needed (again)
09:35:02 <Alberth> sorry, I fail at explaining it :(
09:36:30 <Alberth> consider the output of grfcodec, ie the raw .grf bytes
09:37:24 <Alberth> only some of the bytes there denote action0 and action2 IDs
09:37:52 <Alberth> those bytes are holes, all other bytes are fixed
09:38:12 <planetmaker> right yes. I guess we just talked past eachother and meaning the same :-)
09:38:26 <planetmaker> that's what I meant with NML outputting pseudo-NML
09:38:49 <Alberth> at that level there are no sprites any more, just bytes
09:39:25 <planetmaker> hm, ok. So you mean beyond NFO. But not yet grf
09:40:35 <Alberth> assume grfcodec can do partial compilation, I have 2 parts, throw it in grfcodec, and get 2 bytes blobs with holes
09:41:17 <Alberth> linking is then deciding which blob should go first, computing a value for all holes, and filling them in
09:41:52 <Alberth> then, just copy the blobs in the right order with the right value for the holes straight into the .grf file
09:42:14 <planetmaker> ok. I think now I understood quite well what you mean :-)
09:43:37 <planetmaker> thanks for your patience :-)
09:44:26 <Alberth> this is how linking works with languages like C
09:44:56 <Alberth> where NML is like a C compiler, grfcodec is like an assembler, and ldd is the (dynamic) linker
09:45:44 <peter1138> erm where does ldd fit?
09:46:01 <Alberth> *.c -> *.o, *.s -> *.o, and *.o -> exe
09:46:21 <planetmaker> currently nowhere
09:46:26 <Alberth> peter1138: you're right, it's the wrong name
09:46:44 <Alberth> planetmaker: actually, ldd, does something else :)
09:46:58 <peter1138> <somehypotheticaltool> is the dynamic linker
09:47:55 <planetmaker> I assumed you meant ld, Alberth
09:48:42 <Alberth> in newgrf land, imagine that you have a lot of common code for each .grf. You can copy it into each .grf, but that's wasting memory. Instead, you load the common code once in memory, and connect it to each grf at loading time. That's what ldd does
09:49:05 <Alberth> ld would be the right tool here indeed :)
09:50:05 *** frosch123 has joined #openttd
09:50:17 <planetmaker> ok, how did we end here? :-)
09:51:11 <Alberth> idle conversation about nml inner operation? :)
09:53:37 <juzza1> is it not possible to change the amount of articulated parts depending on cargo_subtype?
09:53:40 <planetmaker> I really miss some compile lecture in order to really dive into NML, I feel :S
09:53:46 <juzza1> i'm always getting the default amount of parts even after refitting
09:54:08 <planetmaker> heqs does so, for instance
09:55:25 <planetmaker> mind, you cannot refit then in stations (autorefit)
09:55:37 <frosch123> i always hoped we would get some grf library
09:55:50 <planetmaker> grf library in what sense?
09:55:50 <frosch123> so not everyone has to reinvent the encoding and decoding :)
09:55:59 <planetmaker> that sense. yes. makes sense
09:56:18 <frosch123> but so far, everyone reimplemented it in a different language :p
09:56:52 <frosch123> grfcodec -> c/asm, grf2html -> pascal, grfeditor ( or what was the name?) -> c#, nml -> python ...
09:56:57 <planetmaker> maybe heqs does that, too, juzza1
09:58:14 <planetmaker> frosch123, but which part exactly should be there?
09:58:21 <planetmaker> action14 block? Needs to be specific.
09:58:40 <planetmaker> Action0 block? Also needs to be specific. As need be the action1/2/3 blocks
09:58:45 <frosch123> no, i mean the grf format
09:58:57 <frosch123> encoding, decoding, sprite assembling, clipping, ...
09:59:17 <planetmaker> ah, that. So a library for the compilers, so to speak
09:59:23 <Rubidium> frosch123: don't you mean grfmaker (or was that an omission), though that was Delphi IIRC
09:59:27 <frosch123> maybe later some nfo action classes
10:00:20 <frosch123> i thought there was also a c# thingie
10:01:16 <Rubidium> might that be the someone who's still converting OpenTTD to C#?
10:03:16 <frosch123> Alberth: there are a lot of global-variable-ish things in nfo, which need reservation
10:03:34 <frosch123> like spritegroups referencing spritesets, or relative jumps to other spritenumbers
10:03:48 <frosch123> offset computations within actions
10:04:04 <frosch123> so the code generator in itself has quite some magic
10:06:40 <Alberth> I feared somewhat that a new NML would be less trivial :)
10:13:42 *** gelignite has joined #openttd
10:23:57 *** HellTiger has joined #openttd
10:28:14 *** |Jeroen| has joined #openttd
10:41:45 *** ZxBiohazardZx has joined #openttd
11:06:17 *** HerzogDeXtEr has joined #openttd
12:18:21 *** George is now known as Guest4778
12:52:33 *** George is now known as Guest4780
13:49:57 *** Devroush has joined #openttd
13:57:08 *** DarkAce-Z has joined #openttd
14:15:56 *** Flygon_ has joined #openttd
14:23:27 *** sla_ro|master has joined #openttd
15:22:58 *** Prof_Frink has joined #openttd
15:41:48 *** Flygon_ has joined #openttd
16:17:53 *** Markavian has joined #openttd
16:20:48 <planetmaker> that's at least an order of magnitude more complicated :-)
16:26:37 <Sacro> this disturbs me very sprites
16:28:02 <oskari89> After those smooth rivers there will be more requests for diagonal roads :)
16:28:22 <planetmaker> I believe you're right, oskari89
16:28:31 <szaman> diagonal bridges and tunnels would be better
16:29:09 <planetmaker> where are the people who want to take on those tasks?
16:30:41 <planetmaker> diagonal bridges has a pre-condition: design specs for complete newgrf bridges ;-)
16:30:58 <planetmaker> everywhere? I haven't seen anyone seriously tackling that for long time. Either of those
16:31:44 <szaman> i want to take on those, but have no time/skills
16:33:20 <planetmaker> skills can be aquired
16:33:55 *** Alberth has joined #openttd
16:33:55 *** ChanServ sets mode: +o Alberth
16:37:22 <planetmaker> ty :-) only temperate yet. And the sprites need revision again, too
16:37:29 <szaman> planetmaker is now knowns as niceriversmaker
16:37:52 <planetmaker> seems that my sprite skills are more in the landscape area :-P
16:38:02 <planetmaker> rivers, shores, trees...
16:38:38 <Alberth> I happen to need some trees in the rct game :p
16:38:53 <planetmaker> How usable are OpenTTD's trees?
16:38:56 <Alberth> (although, Z is likely to provide them :p)
16:39:22 <Alberth> scale is a bit wrong probably
16:39:59 <Alberth> szaman: you have the wrong idea about time. Time is not something you have, you make time by not doing something else
16:40:15 <Alberth> ie it is about choice of what you do and not do
16:42:30 <szaman> Alberth: i can't allow not doing things i now do everyday, some little woman depends on those things, for example now its time to bath :P
16:44:21 <planetmaker> I'd not necessarily think scale is wrong. It's not a big tree then. But rather a big bush. Or a small tree :-)
16:44:37 <planetmaker> Like hazelnut. Or holunder. Or so
16:46:35 <szaman> but in about 17 years the girl will grow up, and then i will do diagonal bridges and tunnels!
16:48:32 <Alberth> szaman: the author of FIRS, CHIPS, and FISH also has kids, and managed to make three great NewGRFs
16:48:41 <planetmaker> is anyone actually still working on any AI?
16:49:56 <szaman> Alberth: it varies over child, some spleeps 3h during day, and some sleeps 3h round the clock
16:50:19 <Alberth> 3 hours of time for free :p
16:50:53 <frosch123> planetmaker: it looks to me like ais are mostly done
16:51:07 <frosch123> there are 3 to 5 which somewhat work
16:51:16 <frosch123> why would anyone need more
16:51:23 <planetmaker> I don't want more
16:51:39 <planetmaker> But I'd like the "somewhat work" to be improved to "work very well"
16:51:39 <frosch123> either you want them for "ambient effects" or for "competition"
16:52:03 <planetmaker> the best AI in my game just crashed.... AIAI. It even had train wood service
16:52:06 <frosch123> well, we failed for 3 years to come up with a decent vehicle weight spec :p
16:53:38 <frosch123> ais do not know about vehicle weights
16:53:53 <frosch123> so they have no idea what vehicle might cope with what hill
16:55:25 <frosch123> there is vehicle weight (empty), cargo weight, power, traktive effort, freight multiplier, slope steepness, acceleration models, ....
16:56:05 <frosch123> the idea was to at least abstractr freight multiplier into the api to increase cargo weight and vehicle weigth or similar
16:56:18 <frosch123> but once you reach max te and slope steepness :p
17:01:15 *** Flygon__ has joined #openttd
17:04:27 <frosch123> newgrf might be complicated, but ottd game mechanics are even more complicated :)
17:05:13 <frosch123> i would think an ai author would want to request an api function, which he gives a consist with orders, a start track, and the function returns the minimum speed on the route :p
17:08:16 <planetmaker> I sometimes wonder whether "less is more" wouldn't be true with some of our historically grown interfaces
17:08:55 <planetmaker> and to start cutting backward compatibility
17:09:13 <frosch123> nah, everyone sees a different part to be "less" :)
17:09:30 <frosch123> just consider the new features for that
17:09:46 <frosch123> take cargodist on one side, and conditional orders and timetables on the other side :)
17:09:49 <Eddi|zuHause> hm, is it too early to say "i survived this day"?
17:10:06 <frosch123> some want to play with this, others with that, but both are completely in conflict to each other
17:10:55 <planetmaker> mostly I was thinking indeed about newgrf specs
17:11:17 <planetmaker> it's too complicated to understand them. Not even OpenTTD can tell what they can do
17:11:35 <frosch123> well, the other specs we came up with were not any better :p
17:11:51 <frosch123> i think improving nml is the better route
17:12:05 <frosch123> most of the nfo stuff you do not even need
17:12:06 <planetmaker> that won't help consist replacement or AIs :-P
17:12:26 <frosch123> so if you support only the important subset via nml, you already have achieved something
17:12:38 <planetmaker> as NML won't stop vehicles being able to drive 25km/h on 8th May only while carryin coal. But passengers other days
17:12:51 <planetmaker> that's true. Something
17:13:11 <frosch123> well, but noone cares whether consist replacement works with "historic vehicles"
17:13:15 <planetmaker> but we can nowhere rely in OpenTTD that newgrfs use only NML's subset of "sane" features
17:14:04 <frosch123> try to support order refitting and order shunting with cargodist
17:14:25 <planetmaker> that's stuff nightmares are made of
17:14:29 <frosch123> i think the idea that every feature shall work with every feature is ill-formed :p
17:14:34 <frosch123> you cannot achieve that
17:14:55 <frosch123> people play ottd differently, everyone uses a different part
17:15:06 <frosch123> you can just blame it on the user if some combinations fails to work
17:15:07 <oskari89> Locomotive detaching from wagons?
17:18:19 <Eddi|zuHause> well, it'll probably hurt more tomorrow :p
17:19:49 <V453000> refit does the same thing basically
17:19:50 <planetmaker> I don't think frosch meant that. But if you have vehicles capable of autorefit in stations, it's virtually impossible to tell which connections do exist or can exist
17:19:59 <Eddi|zuHause> oskari89: that guy never provided his patch, afaik
17:20:27 <planetmaker> thus without knowledge of what connections exist for which cargo, cargodist must fail
17:20:29 <oskari89> I hope he does at some point :P
17:21:54 <V453000> I dont think there would be any real way how to use that though
17:22:28 <frosch123> V453000: as long as there are people who arrange hundreds of trains along a 24 hour timetable
17:22:33 <frosch123> there is also space for shunting
17:22:35 <Eddi|zuHause> Alberth: the "linker" i wrote for CETS does 3 hacks, 1) introduce the "comment" in the code to decide where headers end, 2) filter out everything before this comment to cut away the duplicate headers, and 3) insert some magic to keep the lifetime of certain IDs over the whole GRF
17:23:43 <Eddi|zuHause> and it kinda relies on NML not rearranging statements very much
17:24:32 <Alberth> you get that by itself with partial compilation
17:25:10 <Eddi|zuHause> but the partial compilation would have to deal with the same 3 problems
17:25:15 <planetmaker> I actually looked at that very patch today... but I was scared. I likely could not support it, if there are problems. And I'm not in a good position to judge properly how it might fall on NML's feet i nthe future, if it became official
17:26:06 <Eddi|zuHause> yes, it's pretty hand-crafted towards CETS, and not easily universally applicable
17:26:57 <Eddi|zuHause> but it was kinda the only way to continue CETS in a sane matter
17:27:08 <V453000> frosch123: I havent yet seen anyone arrange hundreds of trains by timetable nor can i imagine how could that possibly work? every timetable breaks sooner or later by jams/whatever
17:27:09 *** Rikests has joined #openttd
17:27:22 <Alberth> Eddi|zuHause: 1 and 2 should not be needed with a proper implementation
17:27:39 <frosch123> V453000: with that kind of timetable there is no sooner or later
17:27:48 <frosch123> all vehicles move deterministically
17:28:28 <V453000> imagine a train gets stuck in traffic for half a year
17:28:45 <planetmaker> V453000, that won't happen if *every* train is on schedule
17:28:50 <planetmaker> it can't get stuck
17:28:53 <Eddi|zuHause> V453000: if you use "full" timetables, trains should not get stuck
17:29:08 <V453000> jams/broken signals/any other issue on the track?
17:29:19 <frosch123> V453000: the timetable arranges the trains in a way they are never stuck
17:29:26 <planetmaker> proper wait times
17:29:40 <planetmaker> so that small disturbances don't escalate
17:29:43 <planetmaker> (like they do in RL)
17:29:46 <V453000> if you have self-blocking signals, then the train is stuck, how does the timetable deal with that :
17:30:00 <frosch123> V453000: every vehicle is timed exactly
17:30:04 <V453000> e.g. your train was stuck for say half a year
17:30:07 <frosch123> it is set up once to work, and then never changes
17:30:23 <planetmaker> V453000, of course you can break the network
17:30:26 <frosch123> "stuck for a half year" is non-sense
17:30:32 <V453000> but how does it react to disturbance like slowdowns, jams
17:30:36 <planetmaker> but... that's something you can always do
17:30:36 <frosch123> it either works, or it doe snot work
17:30:39 <frosch123> but it enver changes
17:30:55 <V453000> if your network just starts jamming
17:31:02 <V453000> - which happens every game -
17:31:14 <frosch123> damn, there is no "starts", when everything is timetabled
17:31:28 <V453000> you add trains at some point
17:31:33 <frosch123> V453000: i think you still did not understand that patch
17:31:50 <frosch123> the vehicles are not timetabled one by one
17:31:54 <Eddi|zuHause> however, besides openttd's current timetables being a pain to set up and manage, big lateness values are problematic, because there is no heuristic when to give up trying to catch up to the timetable. so a 100 day timetable, and 98 days late counter, the train will not try to skip one full round-trip, but instead try 97 days late, 96 days late, etc...
17:32:00 <frosch123> every train is aligned with everyone else
17:32:26 <frosch123> you add one train at a time and configure it's timetable so it does not conflict with any other train
17:32:36 <frosch123> then it keeps on running on exactly that cycle
17:33:33 <V453000> okay, so it is re-calculated after adding every train?
17:33:50 <V453000> and still, even adding just one train does not have instant effect on jams etc
17:33:56 <frosch123> nothing is calculated
17:34:00 <frosch123> it is set up manually
17:35:28 <planetmaker> hm, how do I align different timetables with eachother?
17:35:39 <frosch123> you have a global 24 hour clock
17:35:42 <planetmaker> Just starting the train at the right time / resetting lateness counter?
17:35:53 <frosch123> and you make sure every order list has a length which is a divisor of 24 hours
17:36:03 <V453000> ok, then if I add 100 trains on a certain connection and the connection starts to jam, the travel time is not updated? or?
17:36:15 <frosch123> the 24 hour thingie is just a helper thingie ofc to get natural units
17:36:19 <planetmaker> V453000, no two trains have the same time table
17:36:28 <frosch123> V453000: no, you do not add 10 trains
17:36:32 <V453000> still 100 trains could visit the same station
17:36:39 <frosch123> you add one train at a time and timetable it so it works
17:36:41 <V453000> 100 individual trains
17:36:50 <planetmaker> yes. But they're schedules by you to not be at the same place and time together
17:36:57 <planetmaker> if you don't do that, you do it wrong
17:37:28 <V453000> but what if the "place" where they all meet is a junction, not a station
17:37:34 <V453000> aka a place which is not in the orders but they all visit
17:37:45 <frosch123> they still run the same on every trip
17:37:50 <planetmaker> you see that. As you add them one by one :-)
17:37:57 <frosch123> so you can timetable them so they do not "meet" in junctions
17:38:16 <V453000> they will meet in junctions if you add too many sooner or later
17:38:39 <frosch123> that's just up to you setting up the timetables correctly
17:38:41 <planetmaker> that's when your network is at 100% capacity
17:39:14 <V453000> ok enough, I dont think I should try to understand this type of playing
17:39:28 <planetmaker> drive speed and time is deterministically. thus you can exactly tell whether trains will meet
17:40:10 <V453000> autoreplace == hell ?
17:41:14 <planetmaker> unless you schedule depot visits in the time table anyway
17:41:26 <V453000> more like about the updated stats of the new train
17:41:39 <planetmaker> limit speed in orders
17:41:53 <V453000> the new train can also be slower :P
17:42:00 <planetmaker> or by wagon speed limit.
17:42:54 <frosch123> coop tries to make it complex in some way
17:43:04 <frosch123> other people do it by increasing the micro management
17:43:58 <V453000> well I know, but I wouldnt say this is less complex than normal playing
17:44:16 *** Dark-Ace-Z has joined #openttd
17:44:18 <planetmaker> of course not. And no-one claimed so
17:44:48 <planetmaker> omg... wall of text
17:45:12 <frosch123> yeah, but the screenshot is cool :)
17:45:38 <Zuu> Ah, a graphical time table :-)
17:45:45 <frosch123> but it needs a special kind of people to play with that
17:46:25 <V453000> I still love the word zug
17:46:40 <V453000> almost as lovely as the one for frog
17:47:09 <frosch123> if you say "zug" like that, it sounds like you mean inhaling drugs
17:47:25 <V453000> I know how to pronounce it :)
17:48:35 <planetmaker> I think that patch might give a total kick to some people
17:49:04 <planetmaker> "omg, must have!"
17:49:19 <planetmaker> those realism people
17:49:25 <V453000> well some people are weird :P
17:49:27 <oskari89> I think that is !!!!
17:50:13 <planetmaker> oh, it can likely even be fun to timetalbe the map accurately and efficiently
17:50:26 <planetmaker> SRNW is a piece of cake in comparison :-P
17:51:51 <oskari89> That plus daylength is something awesome :)
17:52:28 <Alberth> so you can play in real time as well :)
18:04:27 <Eddi|zuHause> <V453000> well some people are weird :P <-- says a person in an IRC channel dedicated to a train game
18:07:18 <frosch123> yeah, don't talk to people who are not here
18:34:27 <Rikests> Any way to change NewGRF parameters in saves?
18:41:33 <Mazur> Rikests, only with a time-machine.
18:41:48 <Mazur> Perhaps you can borrow one from a friend.
18:47:58 <Eddi|zuHause> "the impossible just takes a bit longer"
18:55:01 *** Stimrol has joined #openttd
19:06:06 *** Supercheese has joined #openttd
19:21:22 *** Rikests is now known as Rieksts
19:36:45 *** Dark-Ace-Z is now known as DarkAceZ
19:48:38 <Wolf01> ho ho ho.. no, wrong time
19:55:06 <Alberth> practising never hurts :)
20:18:59 <Wolf01> newobjects patch 2, the revenge?
20:19:30 <planetmaker> It's a landscape grf
20:19:36 <planetmaker> with some NewObjects
20:20:14 <planetmaker> exactly four to be precise
20:21:43 <Alberth> perhaps add a <p> before 'English' in the translation output?
20:22:07 <planetmaker> when my repo is in a less modified state :-)
20:22:20 <planetmaker> though... it's a single file I don't touch... yes
20:22:44 <Alberth> discover the concept 'local clone' :)
20:23:20 <planetmaker> or commit and ammend. and unnamed branches :-)
20:23:34 <Alberth> so many strings for a landscape newgrf! :o
20:23:46 <planetmaker> parameters. parameters :-)
20:28:46 <Supercheese> [url]nightly builds[/url]
20:28:54 <Supercheese> or rather, no url specified
20:29:35 <Supercheese> also [url]changed since[/url]
20:30:31 <Supercheese> you're welcome :)
21:42:03 *** Djohaal has joined #openttd
21:47:25 *** parkette has joined #openttd
continue to next day ⏵
