IRC logs for #openttd on OFTC at 2015-02-10
⏴ go to previous day
00:26:47 *** Pikkaphone has joined #openttd
02:05:26 *** shirish has joined #openttd
02:37:35 *** itsatacoshop247 has joined #openttd
04:51:57 *** tokai|noir has joined #openttd
04:51:57 *** ChanServ sets mode: +v tokai|noir
05:23:21 *** HerzogDeXtEr has joined #openttd
05:26:25 *** HerzogDeXtEr has joined #openttd
05:56:17 *** Eddi|zuHause has joined #openttd
06:24:05 *** shirish has joined #openttd
07:40:49 *** Celestar has joined #openttd
09:40:53 *** glevans2 has joined #openttd
10:23:28 *** andythenorth has joined #openttd
10:35:58 *** glevans2 has joined #openttd
11:06:37 *** andythenorth has left #openttd
11:14:40 *** smoke_fumus has joined #openttd
11:14:45 *** itsatacoshop247 has quit IRC
12:08:45 *** zeknurn` has joined #openttd
12:12:46 *** zeknurn` is now known as zeknurn
12:32:25 *** Supercheese is now known as Guest4831
12:32:29 *** Supercheese has joined #openttd
12:41:50 *** andythenorth has joined #openttd
12:55:25 <raincomplex> some of my trains are going right through their current destination station (full load) to the depot after it
12:56:12 <Eddi|zuHause> yes. put the depot before the station.
12:56:24 <Eddi|zuHause> or use a "service at depot" order
12:56:37 <andythenorth> or turn off breakdowns...
12:57:09 <raincomplex> with depots before the stations, i was having problems with other trains coming in there just to service
12:57:14 <raincomplex> and getting stuck
12:57:19 <raincomplex> e.g. behind a bunch of loading trains
12:57:43 <Eddi|zuHause> then put the depot at the mainline.
12:57:50 <Eddi|zuHause> or use a "service at depot" order
12:58:21 * Eddi|zuHause has a "... oder bei OBI" flashback
12:59:08 <raincomplex> i think service at depot order might be the best
12:59:14 <raincomplex> i did forget about those
12:59:34 <raincomplex> luckily my trains are all sharing orders...
12:59:40 <andythenorth> with breakdowns off, this becomes a non-issue
12:59:50 <andythenorth> although some people consider it cheating :)
13:01:28 <raincomplex> it is a neat mechanic though
13:02:06 <raincomplex> my depot layout is regular enough that i think manual maintenance is probably a good option
13:03:47 <Eddi|zuHause> you can also do "pathfinder hacks", e.g. lowering the penalty threshold for finding depots, or increasing the penalty to this particular depot (e.g. by placing reverse path signals or road crossings)
13:04:29 <Eddi|zuHause> but this seems a bit fragile
13:15:32 *** sla_ro|master has joined #openttd
13:15:49 <raincomplex> is there a way to limit the capacity of a depot?
13:16:04 <V453000> why would you want to do that
13:16:21 <raincomplex> trains are stacking up in my depot
13:16:37 <andythenorth> invert the problem
13:16:40 <andythenorth> provide more depots
13:17:07 <andythenorth> also build short trains
13:17:21 <V453000> you can even make it so that trains coming to the depot are less likely to enter it, if trains are leaving the depot
13:17:23 <raincomplex> my trains are all 3 tiles long
13:17:23 <andythenorth> due to the 38mph depot penalty speed
13:17:30 <andythenorth> 3 tiles is short :)
13:17:58 <raincomplex> they'll pick an emptier depot over a full one?
13:18:10 <raincomplex> or just randomly if they're the same distance?
13:18:12 <b_jonas> raincomplex: give explicit service in depot orders
13:18:18 <b_jonas> different ones to each train
13:18:21 <raincomplex> ah to distribute them
13:18:42 <andythenorth> play it like TTD :P One track per train, one depot per track
13:18:52 <raincomplex> that might be painful in my case
13:19:04 <b_jonas> what? TTD doesn't play like that
13:19:06 <raincomplex> i've got 41 trains on this station
13:19:27 <V453000> explicit orders are bad
13:19:31 <andythenorth> b_jonas: eh? Did you play it? :)
13:19:33 <V453000> better do it by signals, you can easily expand that
13:19:46 <b_jonas> it has plain signals and one-way signals
13:19:53 <andythenorth> the winning strategy for trains is one track per train
13:20:06 <b_jonas> maybe, but I've ran two trains on a track in TTD
13:20:16 <b_jonas> or three trains on a double track
13:20:20 <b_jonas> oh, I haven't played TTO
13:20:29 <raincomplex> i haven't messed with priority yet
13:20:33 <raincomplex> i probably should learn that
13:21:27 <V453000> you can do a lot of stuff with depots
13:21:37 <b_jonas> does it have no signals?
13:21:55 <raincomplex> there's a one-way in and one-way out
13:22:09 <raincomplex> the out track tends to back up though
13:22:21 <raincomplex> actually i bet if i can get the out track flowing better, the depot will clear itself up
13:22:52 <V453000> signals like that will make depots empty up much easier
13:23:24 <raincomplex> can it be done path-only?
13:23:28 <V453000> it is because the entering train needs to get 2 green signals before it gets to the depot block, at which point the depotted train gets out earlier
13:23:49 <raincomplex> so is that entry-combo-exit
13:23:56 <raincomplex> entry-combo-depot-exit
13:24:07 <raincomplex> i'll give that a shot
13:24:33 <V453000> with the exit the depot basically has just capacity for 1 train I think even
13:24:40 <V453000> without it it just helps to empty depots
13:30:55 <V453000> so if you want to go ultra realistic or whatnot, you can make 3 tile long depots and place the exit signal there XD
13:31:50 <planetmaker> <andythenorth> or turn off breakdowns... <-- not necessarily. You can enable servicing with breakdown off :)
13:32:26 <raincomplex> the entry/combo/exit signals seem to have done the trick :D
13:42:51 <Eddi|zuHause> <andythenorth> play it like TTD :P One track per train, one depot per track <-- i never played TTD this way.
13:45:01 <Eddi|zuHause> and also not TTO, after a few days of playing the demo.
13:45:18 <V453000> andythenorth is incompatible with playing the game
13:45:36 <Eddi|zuHause> in fact, i played one-way double track with TTO.
13:46:02 <andythenorth> was there some signal trick?
13:46:17 <andythenorth> after a few crashes in games with marginal profits, I stuck to one line per train
13:47:04 <planetmaker> making trains go in circles w/o having them getting stuck was very tricky. It worked marginally. And often not even that :P
13:47:37 <Eddi|zuHause> it was fragile, mostly due to the turn-around-when-waiting behaviour
13:48:07 <Eddi|zuHause> also, you can't have depots...
13:48:22 <Eddi|zuHause> or depots are very tricky
13:48:26 <andythenorth> one day I’ll figure out how to make TextWrangler run the python linter
13:48:34 <andythenorth> then I can stop compiling to find my syntax errors
13:49:47 <planetmaker> andythenorth, doesn't it have one by default?
13:50:12 <andythenorth> oh maybe it does
13:50:54 <andythenorth> I have been occasionally trying to make the pyflakes integration work for last year or so
13:53:25 <andythenorth> also one day I’ll stop trying to iterate None
14:07:07 *** zeknurn has joined #openttd
14:07:44 *** Pensacola has joined #openttd
14:24:25 *** OsteHovel has joined #openttd
14:25:19 *** Eddi|zuHause2 has joined #openttd
14:26:38 *** sla_ro|master2 has joined #openttd
14:29:04 *** Klanticus_ has joined #openttd
14:29:42 *** yorick_ has joined #openttd
14:30:24 *** yorick_ is now known as yorick
14:32:37 *** CosmicRay has joined #openttd
14:32:46 *** ToBeFree has joined #openttd
14:33:04 *** ^Spike^ has joined #openttd
14:33:07 *** luaduck_zzz has joined #openttd
14:33:31 *** XeryusTC has joined #openttd
14:33:33 *** luaduck_zzz is now known as luaduck
14:33:34 *** tyteen4a03 has joined #openttd
14:33:35 *** dihedral has joined #openttd
14:33:45 *** Stimrol has joined #openttd
14:53:04 *** DanMacK has joined #openttd
14:55:58 <raincomplex> does the pathfinder not take into account trains waiting on track up ahead?
14:57:57 <planetmaker> it does take them into account. But they're not a dead end, thus trains can wait for them to continue
14:59:21 *** Eddi|zuHause2 is now known as Eddi|zuHause
14:59:32 <raincomplex> maybe it's this bridge
14:59:38 <raincomplex> let me get a screenshot up
15:00:00 <planetmaker> basically everything has its own penalty. curves, bridges, tunnels, signals, trains, level crossings, waypoints, stations
15:00:59 <raincomplex> they're using those first four platforms almost exclusively
15:01:12 <raincomplex> is it that the entry path is just too long on the 5th and 6th perhaps?
15:01:39 <raincomplex> maybe i need to just reorganize it to be cleaner
15:03:18 <planetmaker> they have very different paths lengths
15:07:21 <Flygon> planetmaker: The way you make the pathfinder sound makes it sound like it dislikes sexy woman
15:07:38 <Flygon> What with those curves, bridges, tunnels, signals...
15:08:16 <planetmaker> you'll also learn that those come with a penalty :P
15:09:05 <V453000> raincomplex: answer is waiting bays
15:09:06 <Flygon> Yeah. Most woman aren't bidirectional :(
15:14:13 <Flygon> Thank goodness I don't show #Openttd my train station designs
15:14:18 <raincomplex> do trains decide where they want to go when they reach a signal, or can they change their minds while they sit there
15:14:24 <Flygon> I'd be punched in the face then convicted of crimes against humanity
15:15:27 <raincomplex> in particular this merge on the outgoing tracks and then splitting to two depots isn't really working too well
15:24:22 <planetmaker> raincomplex, at every junction a train evaluates its path anew
15:24:31 <planetmaker> signals have nothing to do with that
15:24:49 <planetmaker> though on a path signal they need to reserve a path to the next signal
15:25:02 <planetmaker> thus they won't proceed further in their path at that point
15:27:21 <raincomplex> when does a train sitting at a path signal pick its path?
15:29:15 <raincomplex> only when it arrives? or does it keep checking while things are changing up ahead / trains moving through etc
15:31:06 <planetmaker> it re-evaluates the path every so often
15:44:58 *** Kurimus has joined #openttd
15:51:01 *** andythenorth has joined #openttd
15:57:19 * OsteHovel likes the new hirarcial grouping of vehicles ;-)
16:01:14 *** Quatroking has joined #openttd
16:21:11 *** shirish has joined #openttd
16:26:57 *** Alberth has joined #openttd
16:26:57 *** ChanServ sets mode: +o Alberth
16:28:15 *** Progman has joined #openttd
17:25:10 <andythenorth> with interesting results
17:27:39 *** TheMask96 has joined #openttd
17:30:30 <Alberth> you can also try pylint, except it checks for pep-8 style code byt default
17:30:49 <andythenorth> I would fall out with that a lot
17:30:57 <andythenorth> hmm pyflakes hates my FIRS by design
17:31:07 <andythenorth> I import a lot of modules as a way of ‘building’ the app
17:31:11 <Alberth> you can configure pylint too :)
17:31:12 <andythenorth> but then I don’t call them in any way
17:31:18 <andythenorth> so they’re all reported
17:31:29 <Alberth> ah, yeah, pylint also doesn't like that :)
17:31:38 <andythenorth> change FIRS design? :P
17:32:24 <Alberth> the idea is that an import shouldn't do anything important
17:32:50 <Alberth> except perhaps initialization of the imported module itself
17:33:09 <andythenorth> apparently the ‘solution’ to this is to assert the module after import
17:33:12 <andythenorth> which is…interesting
17:33:27 <Alberth> how do you find which modules are imported afterwards?
17:37:19 <andythenorth> they use that dubious self registering pattern I like so much
17:37:33 <andythenorth> so the imports just cause them to appear in a list
17:37:41 <Alberth> you register in some common module or so?
17:38:19 <andythenorth> so industries get stuffed into registered_industries for example
17:38:30 <andythenorth> I suspect it’s a highly wrong approach, but it works
17:38:34 <andythenorth> and it has few LOC
17:38:37 <andythenorth> and /me understands it
17:39:21 <andythenorth> I have a horrible feeling that trying to clean it up will result in loops that call __import__
17:39:26 <andythenorth> which seems…also wrong
17:40:15 <andythenorth> but as I am doing a big rewrite of FIRS, now could be the time to fix it, if it’s broken
17:40:15 <samu> I plan to do some other NewGRF thingy, to prevent some vehicles expiring past 2050, such as helicopters, some ideas I had years ago
17:40:16 <Alberth> the simplest fix is to import all, and then register in a call into the module, or by pulling out some variable from the module
17:40:32 <samu> has anyone done such thing?
17:40:36 <andythenorth> registering the call seems to just double the LOC
17:40:40 <andythenorth> explicit is better I guess :P
17:40:44 <Alberth> but you need to list all module names twice at least
17:41:16 <andythenorth> samu: just turn on ‘vehicles never expire'
17:41:33 <samu> gah, horrible workaround
17:42:13 <andythenorth> import this would fail pyflakes
17:42:41 <Alberth> the nicest imports are the from__future__ import .... :)
17:43:01 <Alberth> not sure if python 3 still has it
17:43:40 <andythenorth> I wish I could do import working_code
17:43:50 <Alberth> samu: you should check how you specify model life of a vehicle, I suspect it always has a finite length
17:44:07 <Alberth> you can, but you first have to write it :(
17:44:30 <andythenorth> I want to import it from the future though
17:44:32 <andythenorth> when it’s done already
17:45:22 <DorpsGek> Commit by translators :: r27142 trunk/src/lang/turkish.txt (2015-02-10 17:45:15 UTC)
17:45:23 <DorpsGek> -Update from WebTranslator v3.0:
17:45:25 <DorpsGek> turkish - 77 changes by wakeup
17:45:51 <andythenorth> after ‘from cargos import beans'
17:45:57 <andythenorth> I could just call ‘beans.register()'
17:46:01 <andythenorth> which would be fine
17:46:09 <andythenorth> just seems a little redundant
17:46:21 <andythenorth> makes me tempted to put __import__ and register() into a loop
17:46:29 <andythenorth> and provide a list of modules
17:46:43 <Alberth> yeah, that would be better here, perhaps
17:46:54 <Alberth> having a double list is also bad
17:47:43 <Alberth> hmm, can't you generate each industry separately?
17:47:57 <andythenorth> I’m sure there are alternative ways to skin this cat
17:48:30 <Alberth> then you could solve this at OS level, by concatenating all output into one nml file
17:49:28 <Alberth> for fname in industries/*.py; do python $fname ; done > industries.nml
17:50:32 <andythenorth> I think it obviates the point of using python
17:50:42 <andythenorth> might as well just write the nml in that case, I think
17:51:14 <andythenorth> can’t render the docs
17:51:22 <andythenorth> can’t have industries refer to each other
17:51:55 <andythenorth> the ‘foo.register()’ method looks increasingly simple
17:52:02 <andythenorth> thoughts are useful :)
17:52:08 <andythenorth> always worth trying a new approach
17:57:41 <Alberth> cargoes look like a INI file to me
17:59:07 <andythenorth> I kind of hated ini parsing when I built FISH that way
17:59:11 <andythenorth> I binned it in the end
17:59:36 <Alberth> ? import ConfigParser ?
17:59:46 <andythenorth> and then split on magic characters
17:59:59 <andythenorth> I don’t think I’d ever use ConfigParser again
18:00:37 <andythenorth> cargos do look like python file is a bit overkill
18:00:42 <Alberth> that's mostly the same idea
18:00:59 <Alberth> industries have the sprite layouts, which is tricky
18:01:01 <andythenorth> but then again, the python markup is actually about as terse as the INI or json
18:01:08 <andythenorth> and there’s no need for a parser
18:01:28 <Alberth> you could throw all cargoes together in one file
18:03:43 <andythenorth> import cargos :P
18:05:01 <Alberth> it's a lot of small little details, don't think you can do much
18:05:26 <andythenorth> cargos in one file is valid
18:05:37 <andythenorth> industries, I just need to explicitly call register()
18:06:17 <andythenorth> magic registration is probably bad magic
18:06:45 <andythenorth> maybe I should write a code generator for the python files?
18:07:11 <Eddi|zuHause> there are probably worse things that autoregistering modules
18:07:30 <Alberth> the trouble is that somewhere you still need to specify all those little details
18:08:00 <Alberth> and it doesn't get much smaller then key = value stuff, which you already have, mostly
18:09:18 <andythenorth> the thing is that it works, and it’s easy to maintain
18:09:23 <andythenorth> but pyflakes hates me
18:09:36 * andythenorth will think about it
18:09:43 <Alberth> the python syntax is a bit of useless here and there, but on the other hand, if you move it to eg INI, where you totally lack python power, it gets worse
18:10:02 <Alberth> so imho pyflakes is just wrong here :)
18:10:30 <Alberth> it's just that you write special python code, which doesn't follow usual code patterns :)
18:11:08 <andythenorth> I’ll drop auto-register
18:11:14 <andythenorth> pyflakes will be happy
18:11:29 <andythenorth> and I’ll commit bugs by forgetting to add an in industry in two places
18:12:27 <Alberth> you can also make pyflakes happy by writing loads of normal python code, and mingle that in your files :p
18:12:50 *** sla_ro|master2 has quit IRC
18:13:48 <andythenorth> I’ll think on, there will be a solution
18:14:28 <Alberth> comlain with the pyflakes authors, challenge them to come up with a good solution :p
18:14:54 <andythenorth> I think the solution would be “don’t let andythenorth write code"
18:17:10 <Alberth> total python lines is 18717, firs.nml is 379984 lines, you must be doing something right :)
18:17:45 <samu> in the nml wiki, what you call of ID, is that the same as identifier?
18:18:33 <Alberth> can you give a page or the nml fragment you talk about?
18:18:43 <Alberth> "nml wiki" is very big
18:19:08 <Eddi|zuHause> ID can also refer to a number
18:19:16 <Eddi|zuHause> depending on context
18:20:48 <samu> there is no page for engine_override?
18:21:23 <Alberth> in that table there is no "id"
18:22:07 * planetmaker considers editing that page and removing the section "TTDPatch / engine pool disabled"
18:22:17 <Eddi|zuHause> samu: that ID is a number that will be used for internal handling
18:22:50 <planetmaker> that page is even linked from the first page
18:23:16 *** sla_ro|master has joined #openttd
18:23:21 *** quorzom has joined #openttd
18:23:53 <samu> i dont want to override an engine from another newgrf, but from the original openttd
18:23:55 <Alberth> planetmaker: move the entire engine pool to the bottom, or somewhere else?
18:23:59 * andythenorth puts in a load of asserts to shut up pyflakes, that will solve it
18:24:19 <samu> model_life: VEHICLE_NEVER_EXPIRES;
18:24:28 <samu> want to add this to some vehicles
18:24:32 <Alberth> so worried about a tool, eh, andy :)
18:24:33 <Eddi|zuHause> samu: then look at the list of original vehicles, and find the ID number there
18:24:43 <samu> but i'm trying to figure out their... that
18:25:19 <andythenorth> Alberth: it’s silly I know, but I want to learn how to work with pyflakes
18:25:27 <andythenorth> and it is no use if the errors are long and spurious
18:25:54 <Alberth> ok, acknowledging is a good first step :p
18:26:00 <andythenorth> distorting the code to please the validator is stupid
18:26:17 <andythenorth> the other validators I use have suppression options, either in the config, or via comments in the code
18:26:25 <Alberth> I just ignore or delete the offending complaints :p
18:26:48 <planetmaker> Alberth, yeah, that likely is a good idea. Though the paragraph above explains how it usually works. Which is good info
18:27:00 <andythenorth> pyflakes may have suppression options, but as it has no docs, who knows eh?
18:27:51 <andythenorth> maybe I should try flake8
18:28:40 <andythenorth> that has suppression, and built in hooks for git and hg
18:29:06 <Alberth> euhm, why would it need git/hg?
18:30:08 <andythenorth> the reason I am learning it is that it has just become an obligatory tool for actual work
18:30:17 <andythenorth> anything failing pyflakes is automatic revert and yelling
18:30:23 <Eddi|zuHause> andythenorth: i think you are overreacting to that warning...
18:30:24 <andythenorth> so I have it set up on a git commit
18:31:01 <Alberth> sounds like a bit blind trust on a tool
18:31:24 <Alberth> in my experience, coding style is a guide, ignore it if there are good reasons
18:32:40 <andythenorth> because it’s ultimately my company, I find it useful to find out how useful each validator is
18:32:47 *** jjavaholic has joined #openttd
18:32:56 <andythenorth> and how much shouting each one is worth
18:33:04 <Alberth> oh, there is nothing wrong with using them
18:33:05 <andythenorth> some are enforced more strictly than others
18:33:49 <Alberth> I just have some trouble with blindly accepting the idea of a tool as the one and only truth
18:34:17 <andythenorth> usually I wouldn’t, and usually we find validators which can be carefully suppressed
18:34:25 <Alberth> you get these Java nanny ideas, thy shall not write dead code
18:34:33 <andythenorth> like the html validator we use which is plain wrong about some html 5
18:34:47 <andythenorth> and the accessibility validator we use which is plain wrong about specific cases
18:35:22 <andythenorth> language validation
18:35:34 <Eddi|zuHause> (thou/thy/... is much easier if you have german grammar in mind :p)
18:36:12 <Alberth> hmm, last german class was in 1983 or so, I think
18:36:40 <Eddi|zuHause> i don't know enough about dutch grammar to judge how it works there
18:36:55 <Eddi|zuHause> well, technically i know nothing about dutch grammar
18:37:04 <Alberth> no, even earlier, 1982
18:37:36 <Eddi|zuHause> Alberth: that was about when i spoke my first german word :p
18:42:24 <Alberth> I quite liked german, but I had to study french instead :( Total disaster, that language :p
18:43:23 *** frosch123 has joined #openttd
18:47:29 <jjavaholic> I have long had problems creating efficient road vehicle goods transportation I I thought one way roads would allow for two tracks of road vehicles and for more traffic down one road/carriage but this doesn't seem to work, I'm looking for ideas how to rectify this. to give you an idea I have a station with 600 vehicles all heading to the same end point
18:48:41 <jjavaholic> I thought one way roads were meant to deal with broken down road vehicles better
18:51:01 <Alberth> maybe with the default RVs
18:51:17 <Alberth> but all newgrf RVs are articulated, and cannot overtake
18:51:53 <samu> can i use these characters when defining a title?
18:51:55 <samu> TITLE :SH '125' (Diesel)
18:52:26 <Alberth> samu: in a .lng file? yes
18:53:26 <Alberth> you can try with a dummy name like TITLE: blabla
18:53:52 <Alberth> if that works, and your text doesn't, you know that the likely source is the text
18:56:01 <andythenorth> really I’m going to rewrite the approach though
18:56:07 <samu> ←[Knmlc ERROR: "expire.nml", line 9: Item parameter 2 'name' should be an identi
18:56:20 <andythenorth> talking to someone somewhere else, I’m violating the rule of ‘imports should change nothing'
18:56:27 <samu> item (FEAT_TRAINS, 22) {
18:56:52 <andythenorth> the import isn’t even idempotent :P
18:57:01 <andythenorth> import industry multiple times, set will break
18:57:09 <Alberth> samu: "identifier" is a name, and 22 is not a name
18:57:21 <Alberth> andythenorth: imports are performed one time only
18:57:32 <samu> 22 is the ID of SH '125' (Diesel)
18:58:29 <Alberth> ie on the first import, the file is loaded and stored, all next attempts to import it will return the stored reference
18:58:42 *** gelignite has joined #openttd
18:58:54 <andythenorth> module registry seems to be a thing
18:59:36 <samu> hmm, then how do I mention the sh 125?
19:01:03 <Alberth> there is a lot of information in the text :)
19:05:19 <samu> item (FEAT_TRAINS, sh_125_diesel, 22) {
19:06:05 <NGC3982> So, what 32bpp NewGRF's should one include in a proper 32bpp server, except RAWR, YETI and the Pinapple trains?
19:06:22 <andythenorth> ho ho ho, this is now spectacularly ugly
19:06:42 <andythenorth> that is absolutely going to increase my mistakes rate, it’s totally impenetrable
19:07:24 <andythenorth> still, it’s much more pythonic now :)
19:07:38 <planetmaker> samu, there's *loads* of example code available for the basics. Including a tutorial at tt-wiki.net
19:08:32 * andythenorth feels a loop against __import__ might appear in a forthcoming commit
19:09:26 <Alberth> I'd add an empty line after each pair
19:09:44 <Alberth> the question is how often do you change that file? :)
19:10:11 <Alberth> it may a bit long, but it's trivial to change
19:13:15 <samu> yay, it works, and i have no idea why exactly, but it works
19:13:30 <samu> SH '125' survived past 2050
19:15:07 <raincomplex> andythenorth, i was about to say
19:15:19 <raincomplex> that really looks like it could use some automation (;
19:15:56 <samu> what diesel engine should be kept past 2050?
19:16:20 <samu> Dash or SH 125? I did for SH 125, but the newest model is Dash
19:19:26 <samu> Personaly I'm more inclined towards SH 125
19:19:51 <andythenorth> Alberth: that file is changed for a few weeks per year :)
19:19:54 <samu> it's faster, and the 'successor' of dash is the Millenium Z1
19:19:58 <andythenorth> and the changes are to add a few lines
19:22:13 <samu> i have other question, about Asia star, sometimes it expires in 2050, and sometimes it doesn't and stays in-game forever
19:31:42 <samu> a random amount between 31 months and 17 years is added to the model life
19:31:54 <samu> explain me this better with an example
19:33:23 <peter1138> Well, see, a random value is added to the engine life cycle...
19:34:42 <samu> i need to know model_life value for AsiaStar, the default value
19:35:41 <peter1138> In one of the table files in the source code.
19:35:59 <samu> oh, good idea, will search
19:37:38 * NGC3982 looks for 32bpp station sets
19:39:13 <planetmaker> good luck, NGC3982
19:39:43 <planetmaker> there was an isr-spin-off. but the original author didn't want that; thus it's only in the forums for now
19:40:12 <NGC3982> I guess there are no particular reason to why such NewGRF does not exist properly yet?
19:40:54 <planetmaker> dunno, possibly not
19:41:01 <planetmaker> maybe one though: nml doesn't do stations yet
19:41:03 <samu> that comparison doesn't have model_life, but vehicle_life
19:41:14 <frosch123> and adding 32bpp to existing 8bpp sets is likely never going to work
19:41:39 <frosch123> it makes no sense if a grf features two different art styles
19:43:20 <frosch123> and CATS is nowhere near done :)
19:47:04 <V453000> I will try to make some more graphics and lure Elyon back again
19:47:18 <V453000> this time I at least have a reliable contact to do so, unlike last year :)
19:47:37 <planetmaker> doesn't sound dead then ;)
19:50:34 <samu> becomes available in 26298 days after 1920-01-01 ... oh great :(
19:52:12 *** Celestar1 has joined #openttd
19:56:47 <DorpsGek> Alberth: 72.0493150685
19:57:36 <samu> a random amount between 31 months and 17 years is added to the model life
19:58:38 <samu> 1992+50+(random value from 31 months to 17 years)
20:04:57 <andythenorth> pyflakes is sad about my python 2 code, because I’m running it under python 3 :)
20:05:04 * andythenorth would like to convert
20:06:43 <NGC3982> 20:41 <@NGCone> Now playing on NGCTTD #1 32bpp (use zBase) RAWR+YETI+Fruity Trains 1901>1960 (Version 1.4.4)
20:06:58 * NGC3982 solved the non-existance of 32bpp station NewGRF's.
20:07:12 <NGC3982> Let's hope players will understand. They usually don't. :(
20:08:13 <V453000> just add 8bpp stations :)
20:09:02 <andythenorth> Alberth: invalid syntax on prints ;P
20:09:19 <samu> i'm confused about these 3 phases
20:09:31 <Alberth> andythenorth: use 2to3? :)
20:09:45 <andythenorth> but it had a lot of problems last time I tried
20:09:49 <andythenorth> in code I don’t understand
20:10:20 <samu> i suck at math, especially when dates are involved
20:10:26 <andythenorth> oh it finds all the python in the templates iirc
20:10:30 <andythenorth> that trips it up :)
20:11:00 <samu> model_life for AsiaStar is 50
20:11:12 <samu> and the vehicle is available in 1992
20:11:43 <samu> so, when will it retire? what would be the years which it can retire?
20:14:08 * andythenorth has stupid imports
20:16:20 <samu> what am i looking at? :o
20:17:06 <samu> okay, at the end of phase 3, the vehicle disappears from purchase list
20:17:15 <samu> but how do I calculate that
20:21:29 <samu> 1992 - asiastar is available for purchase
20:21:58 <samu> 1992 + 7 to 38 months = phase 1
20:24:33 <samu> phase 1 + (50+(31 months to 17 years)-8 = phase 2
20:24:55 <andythenorth> FIRS render_pnml works under python 3 now
20:25:02 <andythenorth> without 2to3 touching it
20:25:09 <samu> phase 2 + (10 to 20.5 years) = phase 3
20:25:09 <andythenorth> render_docs is sulking
20:25:44 *** Progman has joined #openttd
20:26:17 <samu> 1992 + (7 to 38 months) + (50-8 years + (31 months to 17 years) + (10 to 20.5 years = retire date
20:26:35 <samu> 1992 + (7 to 38 months) + (50-8 years + (31 months to 17 years)) + (10 to 20.5 years) = retire date
20:28:30 <Alberth> decide the end point, and decide something for phase 1 and 3
20:29:13 <Alberth> not that the newgrf doesn't take (31 months to 17 years) into account at all
20:37:56 <samu> 1992 + (0.583 to 3.166) + (50-8) + (10 to 20.5) = retire date
20:39:29 <samu> 2044.583 to 2057.666 = retire date
20:40:15 <samu> those 31 months to 17 years are not used in the formula?
20:41:28 * andythenorth nearly has a happy pyflakes
20:41:34 <andythenorth> and the project is slightly cleaner imho
20:41:43 <Alberth> I can only see the model_life property in the vehicle properties
20:42:22 <Alberth> all the other stuff seems out of your control
20:42:37 <andythenorth> Eddi|zuHause has some code for model life stuff
20:42:49 <andythenorth> I gave up bothering about it
20:42:56 <andythenorth> I play ‘vehicles never expire’ anyway
20:43:42 <Eddi|zuHause> samu: the 17 years are in phase 3. early retirement applies relative to end of phase 2
20:43:45 <Alberth> just make sure a new vehicle arrives before the current one expires
20:44:33 <andythenorth> just use 30 or 40 year model life, and deliver a new vehicle every 20 years
20:44:36 <andythenorth> seems about right
20:46:00 <Eddi|zuHause> i set early retirement=vehicle life - 4 years, and model life = purchase time + vehicle life
20:46:31 <Eddi|zuHause> i don't want to bother looking this up
20:46:58 <samu> must make up my mind about AsiaStar retiring before 2051 or not
20:47:11 <samu> past that date it stays permanently
20:47:55 <Eddi|zuHause> if it stays with low reliability, what's the point?
20:48:17 <Eddi|zuHause> also, it might not stay if a NewGRF with planes or ships introduces vehicles after 2050
20:48:35 <samu> no, im not adding new vehicles
20:48:47 <Eddi|zuHause> but the other players might
20:52:22 <samu> what is the interval range?
20:52:37 <samu> just now it retired in Jun 2050
20:54:41 <samu> if i could figure the minimum value
20:57:55 *** HerzogDeXtEr1 has joined #openttd
20:59:14 * andythenorth wants to import modules into the packages __init__.py
20:59:23 <andythenorth> from package import module works
20:59:28 <andythenorth> import module doesn’t
20:59:59 <Alberth> newer pythons allow relative import, never used it though
21:00:24 <andythenorth> just trying to improve readability by reducing redundant characters
21:00:40 <andythenorth> can I spam a ‘from’ import across multiple lines without escapes?
21:00:52 <samu> strange, it retired in year 2052, I didn't expect that
21:01:07 <Alberth> andythenorth: probably not
21:01:30 <samu> i thought vehicles could never expire past year 2051
21:01:38 <Alberth> python needs something around a list to keep it together without escapes
21:02:17 <Alberth> where did you find that samu?
21:05:02 * andythenorth moves industry imports to industries package, ditto for cargos
21:05:10 <andythenorth> seems to be a bit more appropriate
21:06:36 <Alberth> means less editing of firs.nml perhaps :)
21:06:53 <Alberth> euhm, firs.py, that is
21:07:23 <andythenorth> and proper separation of concerns
21:07:52 <samu> again, it expired in year 2052
21:08:05 <samu> there's something I don't understand
21:08:27 <samu> when does the game sets that a vehicle won't expire?
21:08:29 <Alberth> lucky you, I don't understand lots of things
21:09:23 * andythenorth has a growing list of things not understood
21:09:27 <samu> reliability was still decaying past 2051
21:09:34 <andythenorth> there must surely have been an inflection point
21:09:41 <andythenorth> because at the beginning I understood nothing
21:09:52 <andythenorth> which might be akin to infinite list of not understanding
21:09:55 <samu> and sometimes the vehicle disappears in 2052, some other times it stays after that reliability
21:10:04 <samu> after that reliability decay
21:10:07 <andythenorth> at some point it became countable list of things not understood
21:10:29 <Alberth> your knowledge grows :p
21:10:43 <andythenorth> but in proportion to my confusion?
21:10:49 <andythenorth> linearly, or geometric? :P
21:11:11 <Alberth> linear to your knowledge? :p
21:11:13 <samu> Looks like I'm not gonna change asiastar.
21:11:30 <samu> I just wanted to garantee at least 1 engine type for each rail type
21:11:41 <samu> there's still the SH 40 which never expires
21:13:29 <samu> depending on luck, there's an asia star past 2050+
21:13:52 * andythenorth wonders what python 3 is stumbling on in render_docs.py
21:14:15 <andythenorth> did lambdas change?
21:14:24 * andythenorth never understands lambdas
21:14:48 <andythenorth> this is throwing a key error for cargo
21:14:49 <andythenorth> sorted(economy_schemas[economy].enabled_cargos, key=lambda cargo: doc_helper.get_cargo_name(cargo))
21:15:16 <andythenorth> works under 2.6/2.7
21:18:43 <Alberth> what does the error say?
21:19:22 <andythenorth> hmm it’s a big stack actually
21:19:47 <Alberth> just the last part is enough probably
21:20:12 <andythenorth> I misread it as Key error, but it’s a Name error
21:23:36 <Alberth> did you commit your code?
21:24:21 <Alberth> parse blabla line worked for me
21:26:13 <Alberth> I have python 3.4, maybe that makes a difference?
21:26:37 <andythenorth> did you run python src/render_docs.py?
21:26:46 <andythenorth> the makefile runs it under python 2
21:28:10 <andythenorth> looks like I need a new python
21:28:30 <Alberth> you can change the "cargo" variable in the lambda line to something else to eliminate that as source
21:29:03 <Alberth> have a look at chameleon requirements?
21:30:45 * andythenorth gets all the pythons
21:30:55 <Alberth> you have 'cargo' as key somewhere?
21:32:48 <Alberth> try key = doc_helper.get_cargo_name
21:32:59 <planetmaker> Now folks, come forward with a nice titlegame suggestion for OpenTTD 1.5.x :)
21:34:20 <Alberth> past winning entries were always city-ish, weren't they?
21:36:09 <planetmaker> (no 1.3 round2 - that was decreed :P )
21:36:53 <Alberth> lol nightgfx baseset :p
21:37:10 <planetmaker> because we can :P
21:37:29 <planetmaker> I was actually thinking whether I make some screenies with rawr as static newgrf ;)
21:38:23 <Alberth> 1.1 has no index.html
21:38:43 <Alberth> but only 3 entries :)
21:39:05 <planetmaker> it's round2. It always only has 3 entries :)
21:39:27 <andythenorth> I broke all my pythons :)
21:41:46 * andythenorth forsees a trip to the backup drive cupboard :)
21:51:06 <jjavaholic> why have one way roads in game if road vehicles can't overtake?
21:52:09 <frosch123> to prevent road vehicles from taking certain routes
21:52:21 <frosch123> where they would block things or end up on level crossings and similar
21:57:55 <andythenorth> backups are useful
22:01:10 <jjavaholic> why do road vehicles avoid drive through stations by default?
22:03:29 <frosch123> because there may be vehicles loading
22:19:36 *** itsatacoshop247 has joined #openttd
22:23:52 *** andythenorth has left #openttd
23:54:27 <samu> grfid - what do i put here if this is my 2nd newgrf?
23:54:45 <samu> RS\01\01 -> RS\02\01 or RS\01\02 ?
23:55:08 <samu> it's a whole different thing than my first newgrf
23:55:16 <samu> but they can be together
23:56:15 <glx> it's up to the grf writer
23:56:24 <glx> so you can do as you want
23:56:49 <samu> they're independent of each other, they function on their own, but they can also be mixed, hmm
23:58:02 <glx> the only rule is the newgrf can't have the same grfid
23:59:41 <glx> the game doesn't care about the meaning inside the grfid
continue to next day ⏵
