IRC logs for #openttd on OFTC at 2011-06-18
⏴ go to previous day
01:31:35 <core> when a server is set to autoclean companies what does that mean, any that are inactive?
02:22:33 *** fjb is now known as Guest5054
02:26:30 *** rhaeder has joined #openttd
04:56:23 *** Eddi|zuHause has joined #openttd
04:59:58 *** supermop has joined #openttd
05:08:22 *** yorick is now known as Guest5062
06:26:28 *** andythenorth has joined #openttd
06:31:32 *** Cybertinus has joined #openttd
06:48:44 *** Alberth has joined #openttd
06:48:44 *** ChanServ sets mode: +o Alberth
07:02:00 *** George|2 has joined #openttd
07:18:10 <Zuu> and hello everyone else :-)
07:34:07 *** Progman has joined #openttd
07:48:54 *** amkoroew has joined #openttd
08:04:50 *** frosch123 has joined #openttd
08:14:10 *** DayDreamer has joined #openttd
08:36:10 *** sla_ro|master has joined #openttd
08:52:08 * andythenorth ventures into new newgrf wiki for help
08:52:29 <andythenorth> sea of blue links :)
08:52:49 <andythenorth> sorting tables by the action type is not the most usable
08:52:57 <andythenorth> sorting alphabetically would be better
08:53:02 <andythenorth> left-right, row by row
08:54:41 <Terkhen> but having a table is a big improvement over the old sorting
09:03:47 <andythenorth> what happens if I remove some tiles from CHIPS?
09:03:58 <andythenorth> they have been disabled in menus for at least one release
09:04:03 <planetmaker> don't. Just make them unavailable
09:04:18 <planetmaker> and keep them there
09:04:47 <planetmaker> climate availability = 0
09:05:14 <planetmaker> callback for availability years = < 0 or so
09:05:57 <andythenorth> I am not seeing that in spec
09:06:42 <andythenorth> I have cb13 in use already
09:06:51 <andythenorth> but it's unacceptable
09:07:44 <andythenorth> Yexo: any suggestions? ^
09:09:24 <Yexo> planetmaker: that's not possible
09:09:31 <Yexo> andythenorth: just overwrite them with new tiles
09:09:44 <Yexo> as long as the new tiles have the same (track / non-track) status there is no problem
09:09:44 <planetmaker> hm, not possible? :-(
09:10:01 <Yexo> planetmaker: the only way you can disable station tiles is by cb13, which shows them greyed out in the menu
09:10:42 <planetmaker> and interesting how transfering knowledge fails again and again in the newgrf domain ;-)
09:12:00 <planetmaker> the climate availability trick to make something unavailable
09:12:03 <andythenorth> ok so when I add some new tiles, reuse those IDs
09:12:12 <andythenorth> until then, leave them
09:16:05 *** andythenorth has left #openttd
09:19:00 <frosch123> i wondered about sorting them alphabetically, but i also wanted to keep the grouping of vehicles
09:19:22 <frosch123> now they are ordered by id
09:20:13 <planetmaker> that's ok, albeit just ok. But we won't get many more IDs quickly, so...
09:21:15 <frosch123> luckily terkhen assigned a number to towns, else i would not have known where to put them :p
09:25:11 <Zuu> Hmm, regarding sorting of the table, if people want to find something specific, they can use search in their web browser?
09:26:10 <frosch123> someone know how to draw a "color gradient" in gimp (specifically in a layer mask)
09:26:53 <Zuu> It's like 7 years ago or so that Firefox/bird/.. introduced the search bar, and even before that, you could search in web sites.. :-)
09:27:16 <Zuu> frosch123: Use the gradient tool?
09:27:33 <frosch123> you mean "search the gradient tool"?
09:28:02 <Zuu> IIRC there is a gradient tool in GIMP.
09:29:08 <frosch123> oh, it is in the main tool palette, not in the menu :)
09:29:08 <Zuu> works fine here (also in the layer mask)
09:32:37 *** Kurimus has joined #openttd
09:55:21 <planetmaker> frosch123: could you fade the upper white bounding boxes a bit into gray?
09:55:28 <planetmaker> there where the text is
09:55:50 <planetmaker> it's otherwise a bit too contrasty background for text
09:57:32 *** andythenorth has joined #openttd
09:59:15 <frosch123> might try later to tweak the layers masks more
10:13:12 *** douknoukem has joined #openttd
10:19:05 <frosch123> planetmaker: added a white blur
10:21:27 <planetmaker> hm... IMHO that doesn't address the too contrasty background where the text is above the boundboxes
10:21:49 <planetmaker> and the text also looks IMHO nicer w/o white blur
10:22:01 <planetmaker> sorry, just my personal taste :-)
10:22:06 *** JVassie has joined #openttd
10:22:12 <frosch123> i prefer it with blue :)
10:23:30 <planetmaker> frosch123: with blue?
10:23:32 <Zuu> frosch123: Nice idea and well carried out!
10:23:39 <JVassie> i added a few more things to the table
10:26:10 <planetmaker> JVassie: yes, I saw that, nice :-)
10:27:11 <JVassie> so will we be sticking thoroughly to 1 new loco per each of the 4 classes per 10 years?
10:29:44 *** ashledombos has joined #openttd
10:29:50 <planetmaker> I'd not make it a fixed rule. And I'm not sure about 10 years eing the best guideline
10:30:09 <planetmaker> but as a working guide... feasible :-)
10:30:20 <Alberth> perhaps say something about #available engines instead?
10:30:37 <planetmaker> yes, that's more important
10:31:04 <planetmaker> not more than a dozen concurrent engines ;-)
10:31:32 <JVassie> for those who play without persistant engines..
10:31:40 *** Vikthor has joined #openttd
10:31:45 <planetmaker> also for those who do ;-)
10:31:59 <Yexo> that would limit the set to 12 engines total
10:32:27 <JVassie> i play with persistant engines :p
10:32:53 <planetmaker> but probably refits are a bad choice there, too
10:32:55 <Yexo> planetmaker: even the default set has more than 12 different engines, not?
10:33:23 <frosch123> i don't think toyland has 12
10:33:35 <planetmaker> but my feeling is that any nice train set should not provide many more
10:33:51 <planetmaker> or at least have the option to not provide many more
10:34:13 <Yexo> as long as there are not too many concurrently available it doesn't matter imo
10:34:33 <Yexo> limiting the total amount of engines because some players play with persistent engines is not a good idea
10:34:53 <Yexo> if you play with that one you should expect a large number of engines
10:34:57 * Alberth agrees with frosch123
10:36:02 <planetmaker> I guess you might have a point there
10:36:50 <Alberth> Yexo: I find that a huge disadvantage of many vehicle sets
10:37:11 <Yexo> Alberth: a large number of different engines?
10:37:33 <Alberth> yes, too many not-so-interesting choices
10:37:44 <Yexo> but do you play with persistent engines on or off?
10:37:46 <andythenorth> mostly there's one big winningest engine, and a smaller one
10:37:50 <frosch123> Alberth: enable breakdowns
10:37:56 <Yexo> Alberth: that's exactly my point
10:37:56 <planetmaker> the problem for me is the way too fast time progression. Thus I'll never enjoy earlier engines, if I don't use persistent engines
10:38:03 <andythenorth> planetmaker: I agree
10:38:14 <andythenorth> I want a shorter total game span in years
10:38:17 <andythenorth> but the same play time
10:38:18 <JVassie> is there increased daylength in trunk?
10:38:19 <Yexo> there shouldn't be too many concurrently available engines, the total number of engines doesn't matter as long as they're not all available at the same time
10:38:28 <andythenorth> trying to backdate newgrfs to 1830 or so is tmwftlb
10:38:36 <andythenorth> better start around 1880
10:38:52 <andythenorth> I've played a lot now with sets that start early
10:38:52 <JVassie> 1881 is our start date currently
10:39:15 <JVassie> i wrote a timeline guide to the dbsetxl
10:39:18 <Alberth> Yexo: oh, I misread you, I thought you were talking about non-persistent engines, sorry for the confusion
10:39:21 <Yexo> planetmaker: but if fast time progression is the problem, just putting less engines in a newgrf set doesn't solve it in any way
10:39:25 <JVassie> there is just soooo much that happens
10:39:38 <JVassie> its next to impossible without daylength and/or build with pause
10:39:42 <Yexo> as you'll miss out on the early houses too for example
10:39:45 <andythenorth> with sets that start early, the game goes like this: wait about 50 years to make any money with slow engines, then loads of engines appear in 1930 :P
10:39:49 <Yexo> or early industries, in case of sets like firs
10:39:52 <planetmaker> Yexo: it solves in it in so-far as I can then use persistent engines and make my own time progression
10:40:06 <andythenorth> FIRS early-industry support is poor, and I'm not minded to improve it
10:40:10 <Alberth> JVassie: and you still don't have time to enjoy watching your stuff in action :)
10:40:11 <JVassie> only to a point though planetmaker
10:40:14 <andythenorth> gameplay with early-industry is not fun
10:40:28 <JVassie> did anyone read the timeline? :p
10:40:52 * planetmaker watches stuff usually a lot. Thus... Progression even slows down the larger my network gets ;-)
10:41:07 <Yexo> planetmaker: I do the same (that is, when I play :P)
10:41:22 <Yexo> however the proper fix for that would be to introduce a daylength patch of some sort
10:41:48 <planetmaker> I won't argue there
10:42:00 <JVassie> whats stopping daylength getting into trunk?
10:42:23 <planetmaker> Well, I guess this set could have a parameter like "Engines: minimal, normal, all"
10:42:34 <frosch123> JVassie: the patches only want to slow down vehicle introduction, but they change everything thus messing everything up
10:43:10 <JVassie> well something increasing the number of ticks per game day
10:43:17 <planetmaker> that's the problem
10:43:26 <Yexo> that already messes with industry production for example
10:43:26 <frosch123> i.e. they try to show a single date in the statusbar and still introduce the same engine in 1950 and 1960
10:43:37 <frosch123> but that approach breaks everything
10:43:58 <frosch123> instead there should be an economy-date, and a technology-date
10:44:00 <planetmaker> if it were that simple, it'd be done ;-)
10:44:05 <andythenorth> what happened to 'the daylength patch that might actually work"?
10:44:19 <andythenorth> just fake the displayed date :P
10:44:20 <JVassie> easiest solution is to get a couple of mates to play with you, get stuff done 3 times as fast :p
10:44:36 <Yexo> but that means even more time spend looking at the map :)
10:44:46 <JVassie> within 1 company i meant
10:44:50 <andythenorth> 1 current month = 1 week
10:45:01 <JVassie> andythenorth: what time scales?
10:45:09 <andythenorth> change some strings from 'production this month' to 'production this week'
10:45:15 <Zuu> Hmm, what about extending the year with more months?
10:45:23 <andythenorth> don't go mental abstracting it all, just enforce one alternative
10:45:44 <Zuu> Eg month #13, #14, #15 ...
10:45:50 <andythenorth> players who want to turn up and specify that 1 month should take like, 3 hours 22 seconds on their very specific PC
10:45:54 <andythenorth> are not people I want to spend time with
10:46:10 <Zuu> so each year have more days, rather than slowing down the days.
10:46:19 <JVassie> thats not a bad idea Zuu
10:46:31 <andythenorth> nearly all the newgrf code I've seen looks at date, not even sure there's much that can get at ticks
10:46:33 <frosch123> Zuu: dates are available as years/month/day, and in days since whenever
10:46:34 <Yexo> Zuu: that still means all yearly statistics are wrong
10:46:34 <planetmaker> just add more months to the year is a solution
10:46:45 <planetmaker> it has issues, too
10:46:53 <planetmaker> thus every solution so far had issues
10:47:04 <planetmaker> newgrfs mess up things
10:47:09 <JVassie> rewrite openttd from the ground up..
10:47:21 <andythenorth> what are the issues with my idea?
10:47:26 <JVassie> issues with that too :p
10:47:30 <andythenorth> (which I think was also someone else's idea)
10:47:40 <andythenorth> basically game date progression / 4
10:47:40 <JVassie> andythenorth: so change text of a month to a week?
10:47:51 <andythenorth> and all interfaces to dates
10:47:57 <JVassie> problem is it only give you option of x1 or x1/4
10:48:04 <frosch123> andythenorth: the problem is not the gui
10:48:09 <Yexo> andythenorth: same problems as all other ideas so far
10:48:12 <frosch123> but what date to report to newgrfs where
10:48:47 <frosch123> i.e. vehicle introduction date should be faked, vehicle date for visulisation as well, but vehicle aging not
10:49:16 <JVassie> what things actually use ticks already?
10:49:28 <frosch123> industry availability and visual appearance should use a technology-date, but industry producton needs to use an ecnomy-date
10:49:40 <Zuu> Hmm, so the ticks need to get slower. Which means vehicles will move longer between each tick => all sorts of funny problems with car follwing, collision detection etc :-)
10:50:03 <andythenorth> why shouldn't vehicle aging be faked?
10:50:12 <planetmaker> as it affects breakdowns
10:50:13 <frosch123> Zuu: don't change the relation between vehicle movement and production
10:50:17 <planetmaker> and depot visits etc
10:50:22 <frosch123> that seems to break most
10:50:54 <JVassie> breakdowns off is the best setting :p
10:50:57 <Zuu> Okay, so simple just slow everything down?
10:51:16 <Zuu> Have eg. 5 GUI-only "ticks" per each game-tick?
10:51:25 <frosch123> JVassie: breakdowns off removes a main criterion for vehicle selection and makes all engines the same
10:51:31 <Zuu> DoCommands get scheduled for next game-tick..
10:51:52 <JVassie> frosch123: only for those who arent too fussed about aiming for realism
10:52:00 <JVassie> I realise the game is aimed at fun more than realism
10:52:08 <planetmaker> Zuu: slowing down movement and animation is not the solution
10:52:26 <planetmaker> slowing vehicles to a crawl would feel very weired like a lag
10:52:26 <JVassie> planetmaker: he didnt mean slowing it down
10:52:43 <JVassie> just allow 5 visual ticks for every game tick
10:52:59 <planetmaker> but vehicle movement is not visuals.
10:52:59 <JVassie> so after 5 visual ticks, the game has an internal tick
10:53:18 <planetmaker> a vehicle moves. may arrrive. load, unload, whatever
10:53:36 <planetmaker> be sold, be bought,... :-)
10:54:14 <planetmaker> and if vehicles move much more during a year: yearly running costs: what hapens to them? Stay the same? Increase?
10:55:27 <JVassie> planetmaker: a thought
10:55:38 <JVassie> our 1 vehicle per class every 10 years as a rough guide
10:55:50 <JVassie> doesnt take into account steam/diesel and electric
10:56:13 * andythenorth solves daylength
10:56:56 <Yexo> planetmaker: running costs are not really yearly, only the display of them is
10:57:01 <JVassie> could do andythenorth
10:57:02 <Yexo> actually they're updated every x ticks
10:57:10 <JVassie> would need a fake date to go with it though
10:57:22 <JVassie> just a visual fake date
10:58:09 <planetmaker> hm, Yexo but the newgrf specifies a runcost base and run cost property. If that's somehow smeared to a (normal) tick and then just kept for daylength - then it autoadjusts
10:58:23 <planetmaker> JVassie: IMHO that doesn't matter
10:58:39 <andythenorth> could even do daylength parameters in newgrf
10:58:42 <Yexo> planetmaker: there is also a callback for running costs
10:58:49 <Yexo> not sure how often that is called, but quite often
10:58:59 <Yexo> so that means it must be smeared out already
10:59:05 <JVassie> planetmaker: so a person might have to wait 20 years if they run an electrified network? :p
10:59:32 <Yexo> JVassie: you can run diesel trains on electric track, no problem
10:59:41 <andythenorth> would be better if there was a cb for vehicle introduction dates
10:59:48 <andythenorth> otherwise lots of ugly action 7
10:59:49 <JVassie> but not the other way around Yexo
10:59:50 <Yexo> as for the other way around: it's only fitting you have to wait longer for new trains if you use obsolete technology
10:59:53 <JVassie> if you dont have wires
11:00:10 <JVassie> im talking about the early years
11:00:15 <JVassie> 1935 ish to be more specific
11:00:22 <andythenorth> it will be a *bit* confusing for players
11:00:35 <andythenorth> there'll be the intro date shown by openttd
11:00:40 <andythenorth> and the one actually in use by newgrf
11:01:21 <JVassie> the E18 would fit nicelyin 1935 IMO :p
11:02:35 <andythenorth> every newgrf will need parameters
11:02:40 <andythenorth> - desired start date
11:02:47 <andythenorth> - desired game length (years)
11:02:53 <Yexo> in other words: not going to happen, bad idea
11:02:54 <andythenorth> and then lots of nfo maths
11:03:23 <andythenorth> it's borderline a good idea :P
11:03:25 <planetmaker> JVassie: well... in any case we should not go by a fixed rule but consider everything as guide.
11:03:27 <JVassie> the game might hit a virtual dead end if things like daylength arent 'conquered' :p
11:03:47 <planetmaker> Yes, early e-engines make sense. But should not out-perform the better steam ones
11:04:05 <planetmaker> or something... dunno :-)
11:04:16 <Yexo> planetmaker: but if we introduce early e-engines, we should not use the 10-year guideline for those
11:05:36 <andythenorth> assume HEQS currently starts in 1900
11:05:47 <andythenorth> if I make the same vehicles available in 1800
11:05:51 <planetmaker> btw... what about 'silent' upgrades: Like early versions of the same model having slightly worse stats than a model bought years later?
11:06:00 <andythenorth> and double the intervals between vehicles....I get a more interesting gameplay
11:06:10 <andythenorth> I just have to ignore date show in game wrt reality
11:06:30 <planetmaker> also double model lifetime then
11:06:34 <Hirundo> planetmaker: That doesn't work with autoreplace, it's quite annoying in e.g. early NARS
11:06:38 <andythenorth> planetmaker: good point
11:07:10 * andythenorth thinks this might be worth doing
11:07:20 <planetmaker> Hirundo: yes, I know... that's why I ask. I'd not make it a 'milestone' difference. But just the normal progression where applicable / desired
11:07:30 <JVassie> andythenorth: parameter ofc
11:07:31 <planetmaker> like P=1390 -> P=1540 kW
11:08:14 <andythenorth> FIRS would just need intro dates adjusted for industry
11:08:48 <andythenorth> there would need to be a meridian time
11:08:57 <andythenorth> some date where normal date == fake date
11:09:04 <andythenorth> maybe 1930 or 1950?
11:09:27 <JVassie> whats the span of your current version?
11:10:32 <planetmaker> andythenorth: 1950. It's the default start date.
11:10:47 <planetmaker> But still... I'm not sure this newgrf-parameter-time-strecht is the way to go
11:14:17 *** HerzogDeXtEr1 has joined #openttd
11:14:27 <andythenorth> so a vehicle introduced in 2000 against current time base would be introduced in 2050 instead (2:1)
11:14:33 <Terkhen> I finally abandoned it because it was impractical
11:15:08 <Terkhen> if every newgrf needs to agree on the same parameters, it is not something that should be done by newgrfs imo
11:17:17 <planetmaker> [13:15] Terkhen if every newgrf needs to agree on the same parameters, it is not something that should be done by newgrfs imo <-- quite
11:17:18 <Terkhen> I have lost my magical xls file that generated all of the action0, though
11:19:11 <andythenorth> the appeal of my idea is that it's only one 'if' away from succeeding
11:19:22 <andythenorth> 'if' all newgrfs implemented same approach
11:19:29 <andythenorth> there are no technical blockers
11:19:33 <andythenorth> current spec permits it
11:19:37 <andythenorth> and it would solve the problem
11:19:43 <andythenorth> no other solution has been found
11:19:44 <Terkhen> no, they are missing a property
11:20:30 <Terkhen> otherwise you can only increase vehicle life by a small amount
11:22:07 <andythenorth> that's an optimisation :P
11:24:25 <andythenorth> 254 is enough for most vehicles on a 2:1 ratio
11:24:36 <Terkhen> IMO it is required... otherwise with big "daylenghts" you will need to add additional vehicles to fill the holes
11:24:59 <Terkhen> 2:1 is still too low :P
11:25:06 <JVassie> more vehicles the merrier IMO
11:25:23 <planetmaker> then you should play 2ccTS ;-)
11:26:14 <JVassie> purno's monstrosity? :p
11:26:31 <Ammler> the issue with big sets is rather that it will get harder to make good balancing
11:26:43 <andythenorth> balancing is out the window with a big set
11:26:46 <JVassie> some sets are built for realism
11:26:52 <JVassie> wait till you see how amazing the FRSet is ;)
11:27:09 * andythenorth eagerly awaits game balancing outcome of BROS :P
11:27:09 <Terkhen> and if you need to add additional vehicles just to fill holes because of daylenght... forget about balance
11:27:14 <Ammler> well, depends what you mean with realism
11:27:21 <Ammler> good balancing is nice
11:27:44 <andythenorth> eagerly anticipating a release AFAIK
11:27:49 <andythenorth> apparently it will be done soon
11:27:54 <Terkhen> for the spain set (if I finally get around licensing and stuff) I would like to add a setting that limits the number of trains a bit
11:27:58 <andythenorth> despite no-one appears to be working on it
11:27:59 <Yexo> that's the project that had their own forums and lost it 10 times, right?
11:28:08 <Terkhen> the full set could be used by realistic lovers :P
11:28:20 * andythenorth is extra mean about BROS because it's everything the British (English?) are worst at
11:28:29 <Ammler> Terkhen: wouldn't it be better to add a kind of filter to the buy gui?
11:29:02 <Terkhen> what kind of filter can do "group trains by similarity and display only the most representative"? :P
11:29:24 <Terkhen> a filter to the buy gui would be nice, but it does not solve the "too much trains" issue
11:29:26 <Ammler> Terkhen: same filter as you would use with parameter
11:29:30 <Terkhen> as I still need to know about them
11:29:46 <Ammler> too much trains is only a issue in the buy gui, isn't?
11:30:07 <Terkhen> no, it is an issue because I need to check all of them and decide on which one is the best
11:30:20 <Terkhen> checking 30~ mostly identical trains as in 2cc is a pain
11:31:02 <Ammler> 2cctrainset should maybe group some trains with liveries
11:32:19 <planetmaker> Terkhen: well... in a way Ammler is right: if newgrfs had an option to group engines and assign a default engine to the group, the purchase GUI could just show the defaults for the groups - but allow selections of others when the group is somehow opened
11:32:38 <planetmaker> but it'd need both, a new NewGRF property and a GUI addition
11:33:38 <Terkhen> the point is: I don't need that many trains, and the people that want that many trains want to be able to find them easily, on a list
11:33:38 <planetmaker> it could be something between that
11:34:29 <planetmaker> the gui could have a button "show all" vs. "show groups".
11:34:31 <Terkhen> if they were grouped and with a default engine for each group, I would never bother with checking the rest
11:34:39 <planetmaker> thus a filter where the groups are newgrf-defined
11:34:46 <planetmaker> yup, that's what you want
11:34:54 <planetmaker> but not the realism-freaks
11:34:55 <Terkhen> in which way is that different from a parameter?
11:35:08 <planetmaker> it's different as in "can be used in the same game"
11:35:28 <planetmaker> and "can be used for a single engine, when needed, but keeps gui clean in normal cases"
11:35:39 <planetmaker> yes. But liveries should not be a different vehicle
11:35:52 <planetmaker> I'm talking about grouping vehicleIDs
11:36:05 <planetmaker> about hiding vehicleIDs behing a "group leader vehicle ID"
11:36:17 <planetmaker> but only hiding in the purchase GUI
11:36:36 <Terkhen> that sounds like a lot of work just for avoiding a newgrf parameter
11:36:39 <Ammler> Terkhen: the difference is think MP :-P
11:36:54 <planetmaker> it matters for MP servers
11:37:35 <Terkhen> I don't think that changes the issue much
11:38:21 <planetmaker> of course it will also need the newgrf to define the property... but?
11:38:33 <Terkhen> there are a lot of things chosen by parameter already in a MP game, I don't see why this one is special
11:38:59 <planetmaker> the difference is: that a single player then can make the choice. Not the map creator
11:39:19 <planetmaker> thus moving it from a game setting to a GUI setting
11:39:32 <planetmaker> which it ideally can be
11:39:58 <JVassie> you lot still here? :D
11:40:07 <planetmaker> no, we all left. It's just bots chatting
11:40:15 <Terkhen> sounds like a lot of work just for that :)
11:40:43 <planetmaker> Not sure whether it's lots of work. But possibly. It'll need a new property. And a bit of GUI
11:40:55 <Yexo> <planetmaker> the difference is: that a single player then can make the choice. Not the map creator <_ that's not only an advantage for MP games, but also for scenarios
11:41:31 *** Adambean has joined #openttd
11:41:38 <planetmaker> adding the property is easy, I think
11:41:44 <planetmaker> the GUI change is more difficult
11:42:00 <planetmaker> properties rather. One will want it for all 4 vehicles
11:42:13 <JVassie> can someone summarise for me pls? <3
11:42:43 <Terkhen> planetmaker: it should also handle other GUI related stuff
11:42:55 <Terkhen> for example, if I disable all trains of a given railtype, I don't need it appearing in the rail menu
11:43:31 <planetmaker> I don't understand. That doesn't happen even now, does it?
11:44:14 <JVassie> it does before vehciles are introduced
11:44:19 <JVassie> not sure if after theyre all gone though
11:44:22 <Terkhen> it appears as disabled
11:44:37 <planetmaker> uhm... it should not show anymore
11:44:41 <JVassie> i never play without persistant engines :p
11:44:49 <planetmaker> a not-present railtype should not be grayed out, but vanish
11:45:03 <planetmaker> I think it's a somewhat recent change, though, Terkhen
11:45:12 <Terkhen> my point is: if you are going to allow customizing vehicle selection, the patch would also need to tweak other parts of the GUI
11:45:19 <Terkhen> I don't know, I tested on 1.1.1
11:45:47 <planetmaker> that should have it. But... ok, I still don't understand: what other parts need tweaking than the purchase GUI? Maybe the vehicle overview GUI. Yes
11:46:45 <Terkhen> nothing else I think, besides railtypes and maybe road/tram
11:47:20 <planetmaker> railtypes... there are only 16. They don't really need groups
11:47:29 <planetmaker> though it could work there possibly
11:47:58 <planetmaker> road / tram... doesn't make sense to me.
11:48:12 <JVassie> planetmaker but not the realism-freaks <--- OY! :D
11:48:13 <planetmaker> defautl would of course be: if property not set: vehicle is its own group and group leader
11:48:18 <Terkhen> planetmaker: I did not mean groups for railtypes
11:48:28 <Terkhen> what I meant is: if I disable all groups with metro trains, I don't want metro tracks to appear
11:48:45 <JVassie> while were at it on metro tracks
11:49:02 <JVassie> can we make the 3rd rail appear on a specific side dependent on adjacent track? :p
11:49:08 <planetmaker> Terkhen: It's not about disabling the groups. But about collapsing all vehicles in a group to one vehicle.
11:49:19 <JVassie> planetmaker: thats a good idea
11:49:26 <JVassie> as long as the group can be expanded
11:49:35 <JVassie> just a simple case of the newgrf defining groups
11:49:42 <Terkhen> that's even more complicated regarding the GUI
11:49:45 <JVassie> and assigning vehicles to the groups
11:49:53 <JVassie> and choosing a default, no?
11:50:30 <planetmaker> Terkhen: what I envision is a simple button like 'show all', 'show only goups'
11:50:41 <Alberth> JVassie: no, imho. A newgrf cannot predict how a user may want to group his vehicles
11:50:44 <andythenorth> groups is akin to station tile classes
11:50:47 <andythenorth> but with a different gui
11:50:48 <planetmaker> where 'show only groups' means that the newest vehicle of the group is shown
11:50:57 <JVassie> Alberth: wrong sort of groups
11:51:17 <planetmaker> fancy tree gui... I didn't think that far. But might be nice(r)
11:51:21 <JVassie> as planetmaker make said its like station tile class
11:51:27 <JVassie> not like the current 'engine groups'
11:51:39 <planetmaker> yeah, like station classes in a way
11:51:51 <JVassie> thats a damn good idea tbh
11:51:59 <JVassie> it could be a 'class'
11:52:08 <JVassie> you have 1445, 146, 246, 185 etc etc
11:52:15 <JVassie> but one of them is the default
11:52:42 <planetmaker> Terkhen: a tree view indeed sounds very scary to implement :-)
11:52:50 <JVassie> is it possible to set the 'default' of each class to either a) the most recently bought, or b) the most often bought?
11:54:21 * andythenorth has another idea
11:54:28 <andythenorth> don't use vehicle sets with too many vehicles :P
11:54:37 <andythenorth> problem solved, no work needed
11:54:47 <planetmaker> andythenorth: please read again the start ;-)
11:55:29 <planetmaker> so... heqs -> heqs / 10 ?
11:55:52 <andythenorth> what are the groups?
11:56:05 <JVassie> well for example in CETS
11:56:07 <andythenorth> "trucks that can carry coal"
11:56:11 *** TWerkhoven has joined #openttd
11:56:15 <andythenorth> "trucks with between 30t and 50t"
11:56:22 <JVassie> light cargo, heavy cargo, commuter, long-distance
11:56:24 <andythenorth> there's no right answer, nor any reason to choose
11:56:30 <planetmaker> like station classes. Cargo restriction makes no sense, though
11:56:32 <andythenorth> but for a train set you'll get
11:56:34 <planetmaker> as that filter is readily there
11:56:45 <andythenorth> or "passenger" " freight"
11:56:46 <planetmaker> which makes sense there
11:56:47 <andythenorth> neither is wrong
11:56:56 <JVassie> and its up to the newgrf authors
11:57:04 <JVassie> with BROS it could work well
11:57:04 <andythenorth> "6 axle road switchers" / "4 axle road switchers"
11:57:24 <JVassie> Networkers, Sprinters, Turbostars, Electrostars, etc
11:57:55 <andythenorth> I have trouble seeing it working well
11:58:11 <andythenorth> especially with two newgrfs supplying say...trains
11:58:25 <andythenorth> newgrf authors need to then agree a common interface, and they won't do that
11:58:31 <planetmaker> so? They both have their own groups
11:58:37 <planetmaker> groups are per-grf
11:58:41 <JVassie> just like station classes
11:58:48 <andythenorth> sooner just a boolean
11:58:52 <andythenorth> "core" "extended"
11:58:58 <andythenorth> apologies for highlight :P
11:59:06 <andythenorth> newgrf author has to decide
11:59:13 <andythenorth> almost same, without crazy label based system
11:59:44 <JVassie> 3 is better in that case
11:59:50 <JVassie> minimal, normal, extended
11:59:59 <andythenorth> that would be sufficient
12:00:23 <JVassie> planetmaker: you suggested that earlier i think
12:00:27 <JVassie> for something else though
12:00:30 <andythenorth> if he did, he was right :D
12:00:33 <JVassie> was it parameter for CETS?
12:00:38 * andythenorth is being dogmatic :P
12:00:41 <planetmaker> andythenorth: it's not about core and extended. That'd not solve it really, if you have a rather rapid evolution of models
12:00:52 <Yexo> <JVassie> just like station classes <- station classes can be shared by newgrfs
12:01:14 <planetmaker> defining a vehicle by class might work just as well...
12:01:54 <Yexo> yep, they just have to use the same label
12:04:09 <andythenorth> so what is the issue then?
12:04:11 <andythenorth> I've misunderstood it
12:04:24 <andythenorth> rapid model evolution is a problem because...?
12:05:14 <JVassie> too many close bunched models of similar stats
12:05:19 <JVassie> for those non-realism-freaks
12:06:27 <andythenorth> and hiding some fails to solve that because?
12:07:07 <JVassie> thats what the classes suggestion is for :p
12:09:18 <planetmaker> andythenorth: exactly that shall here be the reason for classes: like "show only newest" "show all" vehicles within the single classes
12:09:20 <Alberth> why not an action 14 ?
12:09:27 <andythenorth> I fail to understand correctly
12:09:31 <andythenorth> I shall draw snow instead :D
12:09:37 <andythenorth> in fact, inverse-snow
12:09:39 <andythenorth> to correct a mistake
12:10:01 <Alberth> there is a good bulldozer in the shed that you can use :)
12:11:11 <Alberth> despite that mistake, I really like your snowy tiles, it makes me want to play arctic with snowline at height 1 :)
12:11:59 <andythenorth> I have many more to do ;)
12:12:04 <andythenorth> but they are mostly quite soothing
12:12:16 <andythenorth> it might go a bit faster with advanced sprite layouts
12:12:24 <andythenorth> but that's not available :(
12:30:52 *** Chillosophy has joined #openttd
12:35:37 <andythenorth> whether to keep doing snow overlay by hacky-but-entirely-valid route
12:35:42 <andythenorth> or wait for nforenum to get fixed
12:35:48 <andythenorth> hacky-but-valid I guess :)
12:36:32 <Yexo> andythenorth: I'm trying to fix nforenum right now
12:36:46 <andythenorth> it won't do any harm either way
12:36:53 <andythenorth> if it gets fixed soon, I have test cases
12:37:00 <andythenorth> if not...I have more test cases soon :P
12:37:12 <andythenorth> just incurs a tiny bit of sprite duplication in FIRS
12:44:17 <alluke> watching trucks carrying containers out from brick works
12:44:41 <Alberth> much more efficient than those pallets :p
12:51:21 <Yexo> andythenorth: do you have a testcase?
12:51:38 <andythenorth> I can create one
12:51:43 <andythenorth> I think I have one commented out maybe
12:52:18 <andythenorth> sheepfarm.pnfo has partial support
12:52:30 <andythenorth> it needs the advanced layout adding in sheepfarm_tiles_layouts.pnfo
12:53:57 <andythenorth> and it will need the snow cutting out of the graphic
12:54:17 <andythenorth> Yexo: you want I should do it and provide a patch?
12:54:30 <Yexo> if it's not too much work, please :)
12:54:45 * andythenorth has to find docs for tile format though
12:56:17 <frosch123> andythenorth: note that the format changed a lot since your first testcase
12:57:35 <andythenorth> frosch123: advanced action 2 tiles have one less byte?
12:58:12 <andythenorth> in your example there is a byte missing compared to normal/extended action 2 tile layouts
12:58:15 <frosch123> what makes you think so?
13:02:55 <andythenorth> Yexo: not sure if I got that right, but...let me know if there are problems
13:03:23 <Yexo> it doesn't work, but that can also be because my nforenum fixes are incorrect
13:03:43 <Yexo> ..... or because I ran it with an old nforenum version
13:04:39 <Yexo> but your action2 is invalid
13:04:53 <Yexo> if you use the advanced format you have to specify flags for every sprite, also all building sprites
13:16:18 <alluke> sucks that ships cant dodge each other
13:16:39 <alluke> i have 3-wide canal but still they go trough each outher
13:20:37 <Ammler> alluke: maybe you can control that with buoys
13:21:11 <alluke> cba putting shitload of buoys
13:21:56 *** roboboy has joined #openttd
13:22:10 <alluke> docks should also be able to handle one ship at time
13:22:28 <alluke> so you could build gigantic terminals with many docks
13:22:30 <andythenorth> someone was doing multi-stop docks
13:24:37 <alluke> how do they empty ships from bulk materials like coal?
13:25:05 <andythenorth> cranes, vacuum, excavator
13:25:35 <alluke> isr has cranes but theyre only available before 1950 :(
13:33:03 * andythenorth wonders what a recycling depot should look like
13:33:45 <Eddi|zuHause> planetmaker: in case you're interested, i have here proposal for a prussian railway set (ca. 1880-1925): www.informatik.uni-halle.de/~krause/schema_pr.txt
13:34:31 <planetmaker> yes, I'm interested. Would you actually mind to somehow put that in that tracking table?
13:35:15 <planetmaker> I'll happily add you to the people authorized to edit it
13:35:54 <Eddi|zuHause> i don't have a google account yet
13:36:15 <Eddi|zuHause> not sure if i want one
13:36:33 <planetmaker> would allow you to edit that :-P
13:36:46 <planetmaker> (I have it for not much else either)
13:42:26 <Eddi|zuHause> "Send all my private data to google" -> accept.
13:44:17 <Ammler> are you sure, you need a google account?
13:44:50 <planetmaker> unless we allow editing for everyone, yes, Am
13:45:08 <Ammler> ok, thought, there is also something with keys
13:45:36 <Eddi|zuHause> hm... no mail yet
13:52:23 <Eddi|zuHause> hm... still no mail yet
13:55:32 <Yexo> Eddi|zuHause: waiting on a mail to confirm your google account or for access to the spreadsheet?
14:01:04 <Ammler> btw. is the newgrf spec really just newgrf, no grf specs there?
14:03:45 <Yexo> Ammler: action5 is mostly used by basesets
14:03:58 <Yexo> however only in the "extra" grf, which is technically already a "newgrf"
14:04:11 <Yexo> the "grf" format itself doesn't contain any data, just realsprites / recolour sprites
14:05:16 <Ammler> just wondering, because the ttdp wiki didn't call it newgrf, just grf, afaik
14:06:36 *** _goblin_ has joined #openttd
14:27:26 <Eddi|zuHause> so, apparently mails from google take half an hour
14:28:29 <frosch123> wolfi had to read them first
14:30:00 <planetmaker> I mean... we all know we cannot trust you ;-)
14:30:17 <planetmaker> also you are a potential terrorist ;-)
14:30:40 <planetmaker> like all of us actually
14:35:54 <Eddi|zuHause> what's with the 99.x engines in the table? we want to include narrow gauge?
14:36:49 <planetmaker> that's indeed a narrow gauge
14:37:14 <frosch123> Eddi|zuHause: test for presence of a railtype label, resp. add parameters
14:37:19 <Eddi|zuHause> and "usage" might want to differentiate between "commuter" (short distance, high capacity) and "local" (short distance, low capacity)
14:37:52 <frosch123> some want to play with different railtypes, others fear the hassle of conversions
14:38:33 <Eddi|zuHause> planetmaker: so what about those edit rights?
14:38:45 <planetmaker> I need your google login
14:38:58 <Eddi|zuHause> that's my e-mail if you have that one
14:39:43 <planetmaker> that'd be it, yes. But I don't know it
14:40:11 <Eddi|zuHause> i'm fairly sure i sent you emails before ;)
14:40:26 <Alberth> so sent another one ;)
14:41:11 <Eddi|zuHause> you can also shuffle around the informatik.uni-halle.de/~krause urls to get my email adress ;)
14:41:35 <planetmaker> or you could just tell me now via private msg here ;-)
14:42:31 <Eddi|zuHause> nah, that's like saying "i'm the computer" in the turing test :p
14:43:21 * Alberth is convinced pm is a person already
14:45:58 <planetmaker> Eddi|zuHause: well, I guess we won't get anywhere this way
14:47:24 <Yexo> Terkhen: afaik they're forced to care about that
14:47:33 <Yexo> but I don't think they can actually query that flag
14:47:50 <Terkhen> ok, I was wondering if that description applied to OpenTTD too :)
14:48:38 <planetmaker> news message: "computer AI destroyed the historical parliament building in XXX-town."
14:49:00 <planetmaker> or the Eiffel-tower ;-)
14:49:18 <planetmaker> hm... what about a monuments add-on houses set? :-)
14:49:38 <Terkhen> players would complain that they can't build specific houses :P
14:50:08 <Ammler> the ecs tourists set is already a kind of
14:51:02 <planetmaker> Eddi|zuHause: so if you care, delete the narrow gauge stuff from it
14:51:08 <Terkhen> yes, maybe special buildings like those make more sense as objects or industries
14:51:16 <planetmaker> I might not have paid close enough attention to the gauge
14:51:36 * planetmaker assigns selection of engines to eddi ;-)
14:52:05 <Eddi|zuHause> we can keep narrow gauge stuff and decide whether to include that later
14:52:25 <planetmaker> Terkhen: both is not ideal either: industries interfere with other industry sets. And NewObjects are not automatically built
14:53:00 <planetmaker> also... I'd make them as houses "upon map creation only" and then maybe provide them additonally as NewObjects for the player who cares
14:54:45 <Terkhen> automatically build newobjects? :P
14:58:47 *** George|2 is now known as George
14:59:40 <planetmaker> I'd like that, yes
14:59:52 <planetmaker> but not prior to river creation ;-)
15:01:00 <Terkhen> automatic newobject build would probably be easier :P
15:02:30 <planetmaker> possibly... though it has to make sense, too
15:02:35 <Eddi|zuHause> not sure why we need two versions of the E10 which would hardly be graphically differentiable
15:05:50 <fjb> Could be implemented as an upgrade like Pikka does in his plane set with the 747.
15:07:45 *** Kurimus has joined #openttd
15:07:49 <Eddi|zuHause> "upgrades" are evil because autoreplace can't handle them
15:08:13 <Eddi|zuHause> possibly needs a grf-spec extension
15:11:06 <planetmaker> Eddi|zuHause: I'm sure we don't need both. I added them so that we could see and choose
15:11:23 <Eddi|zuHause> your engine list looks fairly random :p
15:13:10 <Eddi|zuHause> quick request: need two abbreviations that differenciate DB (west) and DB (unified)
15:13:58 <planetmaker> Eddi|zuHause: my engine list IS fairly random
15:14:07 <Eddi|zuHause> fjb: that's good
15:14:26 <Yexo> out of curiosity, what does the AG stand for?
15:14:37 <planetmaker> Aktiengesellschaft
15:14:51 <planetmaker> i.e. a company with share holders
15:16:08 <Eddi|zuHause> with one shareholder, currently ;)
15:16:15 <planetmaker> fjb: you also want edit rights?
15:16:40 <Eddi|zuHause> misses lots of things
15:16:41 <planetmaker> I don't claim to have much knowledge about what should go and what not
15:17:20 <Yexo> Eddi|zuHause: "express" = "express cargo" ?
15:17:28 <fjb> Hm, don't think I need edit rights yet.
15:17:28 <Eddi|zuHause> no, express passenger
15:17:57 <planetmaker> ah... that's what I'd have called long-distance ;-)
15:18:06 <Yexo> so if express means express passengers, and I assume "local" is "local passengers", what is "passenger"?
15:18:06 * fjb has a book about all engines of the DR.
15:19:15 <planetmaker> fjb: so you could make a good list? :-D
15:19:23 <fjb> Hm, or would I need edit rights? Don'tz know yet.
15:19:38 <fjb> planetmaker: May be I could expand your list a bit.
15:20:03 <planetmaker> fjb: preferrably I leave the list to people who actually know engines.
15:20:13 * planetmaker never was a railway historian
15:20:39 <fjb> There are a lot of pictures in the book.
15:20:44 <planetmaker> I'll happily discuss game balance, but the historic correctness or choice is beyond me
15:21:37 <Eddi|zuHause> Yexo: should probably make a legend ;)
15:23:20 <Eddi|zuHause> where can i change "alignment"?
15:24:12 *** fjb|mobile has joined #openttd
15:27:30 *** supermop has joined #openttd
15:30:26 <Eddi|zuHause> Yexo: now better?
15:31:33 <planetmaker> Eddi|zuHause: could you add the time for the companies?
15:31:56 <planetmaker> it's clear that the Preussische Staatsbahn doesn't operate anymore, but... :-)
15:33:07 <planetmaker> I guess DR = DDR and DRG = pre- WW2?
15:35:10 <supermop> am just catching up on a few months of forum reading,
15:36:56 <supermop> you seem to be on to a concern I have had for a while re: max speeds and 2cc set
15:38:51 * fjb|mobile has a book about DRG, not DR.
15:40:10 <planetmaker> fjb|mobile: you should share your knowledge then ;-)
15:41:33 <Eddi|zuHause> planetmaker: do the entries in the list need to follow a particular order or are they suppsed to be reordered at will?
15:42:24 <fjb|mobile> planetmaker: I guess I should...
15:42:30 <planetmaker> I've no order yet, Eddi|zuHause
15:42:43 <planetmaker> they should follow a order which make it easy to see which engines we need :-)
15:42:57 <planetmaker> I started with a time line roughly
15:43:01 <planetmaker> but that might not be best
15:46:26 <Eddi|zuHause> no, that's why i ask ;)
15:46:52 <Eddi|zuHause> we probably need a column deciding "core" and "extended"
15:50:11 <planetmaker> yes. eventually at least. I'd only start with core, though
15:52:04 <Eddi|zuHause> hm... no, i'd make it the other way round, include all engines that sound interesting, and then successively remove them until you get a tidy "core" set
15:52:38 <fjb|mobile> We should have both tables to move vehicles between them.
15:52:42 <Eddi|zuHause> look at my schema above, there are 40 engines on there, a "core" set for that period should probably not exceed 20
15:53:12 <Eddi|zuHause> means half of them need to be carefully weighed to be removed
15:57:27 <planetmaker> [17:52] Eddi|zuHause hm... no, i'd make it the other way round, include all engines that sound interesting, and then successively remove them until you get a tidy "core" set <-- sounds like the way I'd to it, too
16:06:07 <Eddi|zuHause> early electrics have very short lifetime
16:06:24 <Eddi|zuHause> (might be a disadvantage to balance them against steam)
16:08:12 *** valhallasw has joined #openttd
16:08:12 <fjb|mobile> They should have lower running costs.
16:29:23 *** douknoukem has joined #openttd
16:34:45 <fjb|mobile> I should have the stats.
16:36:34 *** andythenorth is now known as Guest5108
16:36:35 *** andythenorth has joined #openttd
16:39:13 <Eddi|zuHause> planetmaker: which source said that the P8 was built until 1938?
16:43:48 <planetmaker> Eddi|zuHause: the "Lexikon der Lokomotiven", by Klaus Eckert and Torsten Berndt, published by Komet Verlag
16:45:27 <planetmaker> it also mentioned that the engine was also built in Poland and Romania, but without giving the years there
16:47:07 <Eddi|zuHause> hm, maybe they included some sub-series that i did not include when making my list
16:54:59 <Eddi|zuHause> planetmaker: wikipedia says until 1923, but also mentions production in romania without giving a year
16:55:49 <planetmaker> well... I've no means to judge the goodness of their investigation nor do I know their data basis
17:01:55 *** Biolunar has joined #openttd
17:11:06 *** doug713705 has joined #openttd
17:13:27 *** DayDreamer has joined #openttd
17:14:43 <doug713705> I have setted up a server which is started with the -g parameter to load a scenario file. But when the game is over, the server restart with a random map and that is not what i'd like. How to tell openttd to reload the same scenario file at restart ? I found no parameter in the config file.
17:15:02 <doug713705> this server is running the latest satble version
17:15:12 <Yexo> as far as I know that's not possible
17:15:46 <doug713705> that's an answer ! Not the one i'd like to hear, but that is one answer :-D
17:16:40 <planetmaker> you could script it though to load the scenario again. But that needs some external tools like ap+
17:17:10 <planetmaker> or you need to write something to connect to the admin port and give the command via those means
17:17:29 <doug713705> I can manage this with a cronjob or something but I was looking for a native solution.
17:17:48 <planetmaker> yeah, sorry, that doesn't work :-)
17:17:52 *** rhaeder1 has joined #openttd
17:19:04 <doug713705> No problem with that, at least I can stop looking for something that is not possible :-)
17:19:41 <doug713705> Thanks for you answers guys.
17:26:32 *** doug713705 has left #openttd
17:29:57 *** Biolunar has joined #openttd
17:36:44 <DorpsGek> andythenorth: DanMacK was last seen in #openttd 1 week, 2 days, 23 hours, 51 minutes, and 27 seconds ago: * DanMacK waves
17:36:57 * andythenorth is worried that DanMacK is bored of sprites :o
17:37:01 <andythenorth> this would be sad
17:45:15 <CIA-2> OpenTTD: translators * r22596 /trunk/src/lang/ (esperanto.txt portuguese.txt):
17:45:15 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:15 <CIA-2> OpenTTD: esperanto - 21 changes by Christopher
17:45:15 <CIA-2> OpenTTD: portuguese - 1 changes by JayCity
17:48:11 <Eddi|zuHause> planetmaker: what to do if i don't have TE, only the "Reibungslast"?
17:50:43 <Terkhen> it is possible to have houses producing cargos different than passengers and mail?
17:51:32 <Eddi|zuHause> Terkhen: same as industries, i presume
17:51:45 <planetmaker> Eddi|zuHause: good question :-). Note down that?
17:52:31 <Terkhen> hmm... it is possible, but it needs a callback
17:52:50 <Eddi|zuHause> "in theory" it would simply be µ*m*g
17:53:03 <Eddi|zuHause> what's µ typically? 0.035?
17:53:35 <planetmaker> something of that order
17:54:11 <planetmaker> just use the value with that approximation, I think
17:54:33 <planetmaker> and maybe add a footnote that it was obtained by these means
17:54:36 <Eddi|zuHause> hm... my table says steel on steel (dry): 0.15
17:54:40 <Terkhen> are you doing a csv -> code conversion?
17:54:58 <Eddi|zuHause> and 0.002 for rolling resistance
17:55:29 <planetmaker> Terkhen: currently we only have a google docs version
17:55:50 <planetmaker> For the actual rolling stock we might consider such thing indeed
17:55:59 <Yexo> Terkhen: there are no plans for that, but if that saves work it's quite likely
17:56:01 <Eddi|zuHause> @calc 34700*0.15*9.81
17:56:01 <DorpsGek> Eddi|zuHause: 51061.05
17:56:23 <planetmaker> it might make some balancing easier. But... yes :-)
17:56:28 <Eddi|zuHause> 51kN? is that low for a steam engine?
17:56:58 <frosch123> compared to the other engines, it is pretty low
17:58:29 <JVassie> good work on the spreadsheet someone
17:58:38 <Eddi|zuHause> @calc 60000*0.15*9.81
17:59:11 <Eddi|zuHause> there must be something wrong with my physics
17:59:11 <frosch123> what is the total weight of the engine?
18:00:01 <Eddi|zuHause> around 60t total, around 34t "active"
18:00:58 <JVassie> planetmaker: shouldnt the short names be like BR150 rather than just 150?
18:01:24 <planetmaker> ask Eddi|zuHause , he's the professional ;-)
18:02:00 <Eddi|zuHause> JVassie: since all engines would have "BR", there's no sense in repeating it. makes it shorter.
18:02:18 <frosch123> @calc 157/84000/9.81
18:02:18 <DorpsGek> frosch123: 0.000190524731809
18:02:26 <JVassie> what are we going to use as a display name then Eddi|zuHause?
18:02:38 <frosch123> @calc 157000/84000/9.81
18:02:38 <DorpsGek> frosch123: 0.190524731809
18:02:47 <Eddi|zuHause> JVassie: some variant of the long name
18:03:05 <Eddi|zuHause> it's fine like it is
18:03:21 <Eddi|zuHause> also, there already is another hidden column, should we indeed need one ;)
18:03:33 <JVassie> well thats for variant name
18:04:02 <Eddi|zuHause> JVassie: i don't think we'll need those
18:04:30 <JVassie> I presume we decided on a minimal/normal/extended?
18:04:45 <JVassie> or just core / extended?
18:04:54 <frosch123> @calc 157000/51000/9.81
18:04:54 <DorpsGek> frosch123: 0.313805440627
18:05:36 <JVassie> I like the new 'useage's too
18:05:41 <JVassie> better to split pax into 4
18:06:09 <Eddi|zuHause> i don't see the need for "minimal"
18:06:27 <frosch123> Eddi|zuHause: the e01 seems to have double µ than normal
18:06:30 <Eddi|zuHause> but could easily add that later
18:06:44 <JVassie> if were going to have an extended option, may as well make use of it :D
18:07:06 <JVassie> that way we can cater for both realists and 'funists'
18:07:13 <JVassie> which is a good thing IMO
18:09:16 <frosch123> that page lists both starting-TE, total weight and useful weight
18:09:34 <Eddi|zuHause> yes, and starting-TE is missing from the steam engines
18:10:18 <Eddi|zuHause> maybe they calculated with sand?
18:11:26 <fjb> Eddi|zuHause: E06: 110km/h, 2780kW, 111,6t
18:12:09 <Eddi|zuHause> hm... i entered 2330kW here
18:12:55 <fjb> Leistungskennziffer (whatever that is) 25kW/t
18:13:53 <Eddi|zuHause> fjb: i took the "dauerleistung" rather than the "stundenleistung"
18:14:10 <Eddi|zuHause> maybe we should decide on one or the other beforehand
18:14:46 <fjb> I also have "Geschwindigkeit bei St.lstg." 67km/h
18:15:41 <Eddi|zuHause> @calc 34700*0.35*9.81
18:15:41 <DorpsGek> Eddi|zuHause: 119142.45
18:15:59 <Eddi|zuHause> so... 119kN, better value for a steam engine?
18:16:16 <frosch123> yes, but 0.35 is quite maximum µ
18:18:21 <Eddi|zuHause> @calc 31.9*0.35*9.81
18:18:21 <DorpsGek> Eddi|zuHause: 109.52865
18:18:24 <JVassie> that legend is quite bulky :x
18:18:52 <Eddi|zuHause> JVassie: if you know a trick to hide it in something like a dropdown?
18:19:13 <JVassie> would be easier to put at bottom of sheet IMO
18:19:45 <JVassie> and can only see 7 rows of actual table at a time :p
18:20:59 * planetmaker doesn't see more rows either for the same reason
18:21:20 <JVassie> then it can be shown/hidden when needed?
18:21:42 <Eddi|zuHause> i put it to bottom now
18:22:17 <Eddi|zuHause> but that may be of trouble later when one wants to sort columns
18:22:31 <Eddi|zuHause> JVassie: unfinished
18:33:22 <CIA-2> OpenTTD: rubidium * r22597 /branches/1.1/ (6 files in 3 dirs):
18:33:22 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
18:33:22 <CIA-2> OpenTTD: - Fix: Callback result for airport layout name was incorrectly used (r22496)
18:33:22 <CIA-2> OpenTTD: - Fix: Airport preview sprite can depend on the layout, so update the cached SpriteID when the layout changes (r22494)
18:33:22 <CIA-2> OpenTTD: - Fix: Engine IDs for coal and mail wagons were swapped in the TTO savegame conversion [FS#4622] (r22487)
18:33:24 <CIA-2> OpenTTD: - Fix: The caption of centered windows could be moved out of the main window and thus become inaccessible when resizing the main window (r22485, r22484)
18:37:12 <CIA-2> OpenTTD: rubidium * r22598 /branches/1.1/ (11 files in 6 dirs):
18:37:12 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
18:37:12 <CIA-2> OpenTTD: - Fix: [NoAI] Doing rescan_ai in a game with running AIs caused a crash [FS#4631] (r22534)
18:37:12 <CIA-2> OpenTTD: - Fix: Do not create an implicit order if the current order is the first order in the order list and we visit the station of the last entry of the order list (r22532)
18:37:12 <CIA-2> OpenTTD: - Fix: MinGW 64 related compilation issues [FS#4623] (r22522, r22491, r22490, r22489)
18:37:14 <CIA-2> OpenTTD: - Fix: The layout selectors of the airport build GUI did not latch properly (r22497, r22495)
18:40:48 <frosch123> the narrow gauge engines in that table are listed 10x longer than they are
18:42:04 *** Biolunar has joined #openttd
18:42:20 *** Chillosophy has joined #openttd
18:47:09 <Eddi|zuHause> planetmaker was responsible for those...
18:54:16 <Eddi|zuHause> the engines with low number, like T2 are no real homogenous series
18:56:25 <Eddi|zuHause> more like "we put all older engines with low power in there"
18:58:54 <Yexo> there are only 0x80 IDs available for actionF, and afaik they can't be reused. Each actionF can contain 255 parts
18:59:11 <Yexo> does this mean the total number of townnames per newgrf is limited to 0x80*255?
18:59:23 <andythenorth> planetmaker: auto-fencing FTW ;)
18:59:55 <planetmaker> OpenTTD > r22518 required though ;-)
19:01:14 <frosch123> Yexo: if you do not combine parts, then yes
19:01:24 <Yexo> frosch123: combine parts?
19:02:03 <frosch123> only names of a single part, no concatenations
19:20:09 <CIA-2> OpenTTD: rubidium * r22599 /branches/1.1/ (11 files in 6 dirs):
19:20:09 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
19:20:09 <CIA-2> OpenTTD: - Fix: Clear airport persistent storage on construction/removal of airports (r22552)
19:20:09 <CIA-2> OpenTTD: - Fix: Possible crash when opening the airport build window for the first time [FS#4619] (r22538)
19:20:09 <CIA-2> OpenTTD: - Fix: Replace the half small airport structure on the intercontinental airport with some grass [FS#3494] (r22537)
19:20:10 <CIA-2> OpenTTD: - Fix: Documentation omission regarding admin protocol [FS#4632] (r22536)
19:40:58 <CIA-2> OpenTTD: rubidium * r22600 /branches/1.1/ (9 files in 3 dirs):
19:40:58 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
19:40:58 <CIA-2> OpenTTD: - Fix: PBS order forecasting modified the current order index in case of a goto-nearest-depot order and no depot could be found [FS#4641] (r22589)
19:40:58 <CIA-2> OpenTTD: - Fix: Remove BaseStorageArrays from _changed_storage_arrays on destruction (r22583, r22551)
19:40:58 <CIA-2> OpenTTD: - Fix: Do not increment STL iterators after they've been invalidated (r22582)
19:41:00 <CIA-2> OpenTTD: - Fix: Do not lower the arrow buttons in the NewGRF/AI parameter windows if they are clicked when disabled (r22553, r22499)
19:43:53 <CIA-2> OpenTTD: rubidium * r22601 /branches/1.1/ (6 files in 3 dirs):
19:43:53 <CIA-2> OpenTTD: [1.1] -Backport from trunk:
19:43:53 <CIA-2> OpenTTD: - Add: Makefile support for bundling pdb and running regressions with the MSVC makefile (r22581, r22580, r22576)
19:43:53 <CIA-2> OpenTTD: - Fix: Do not show cargo accepted/produced in the new station window when no tiles are selected (mouse hovering a window or toolbar) [FS#4647] (r22595, r22593)
19:43:54 <CIA-2> OpenTTD: - Fix: Add active NewGRFs to the list of available ones when selecting the empty preset [FS#4644] (r22594)
19:43:54 <CIA-2> OpenTTD: - Fix: Reading of heightmaps with uncommon BMP formats failed due to uninitialised variables [FS#4645] (r22592)
20:05:45 <m> someone here who knows how to reverse-engineer with IDA Pro? I'm trying to decompile Earth Siege 2 and have some questions with Borland C++ vtables
20:06:27 <Yexo> I've used it before, but not so much that I can answer any questions about it
20:23:02 <Eddi|zuHause> that was quite a coincidence :p
20:23:31 <Eddi|zuHause> (if you believe in such things)
20:28:21 <frosch123> Eddi|zuHause: do you believe in the coincidence that the index of the newtrains-switch (0x37) incremented by the id of the action4-original-strings-feature (0x48) results in 0x7f, which turns out to be the a patch switch, which is always set?
21:45:52 *** douknoukem has joined #openttd
21:50:53 *** tokai|mdlx has joined #openttd
22:07:32 *** jewoodall has joined #openttd
22:07:55 <jewoodall> Hi folks! Can I ask about something I'm running into?
22:09:21 <jewoodall> Wow. Okay. Should have read the topic. I have a mine and forest, with a train station inbetween. I send a train with 1 ore and one wood car into the station, and NOTHING gets loaded onto my train.
22:10:36 <Yexo> are you using any newgrfs?
22:11:08 <jewoodall> Did the default Windows download last night.
22:11:19 <jewoodall> Showing OpenTTD 1.1.1
22:11:38 <Yexo> if you click the mine, you'll see which cargos in can produce
22:11:42 <jewoodall> No customs, all defaults accepted. I just switched to using only one car, that being the wood car.
22:11:57 <jewoodall> 88 tons iron ore. 28% transported.
22:12:21 <Yexo> do you realize that a forest doesn't accept iron ore? you need to transport iron ore to a steel mill
22:12:25 <jewoodall> Forest reads 168 tonnes wood, 26% transported.
22:12:55 <jewoodall> Oh, yeah, I was being literal. In the east, I have a station. That station is smack between a forest and a mine.
22:13:11 <Yexo> wood from the forest needs to be transported to a paper mill or sawmill, depending on the climate
22:13:22 <jewoodall> In the southwest, I have another station. It is located close to a sawmill and a steel mill.
22:13:51 <jewoodall> SW station says accepts "Passenger, Wood, Iron Ore". Waiting: Nothing.
22:14:01 <Yexo> if you open the train details, how much cargo is already in the train?
22:14:21 <jewoodall> East Station says Waiting 305 wood and 304 ore.
22:14:28 <Yexo> train details can be found by clicking on the train, than the lowest button at the right
22:14:42 <Yexo> what are the orders for your train?
22:14:52 <jewoodall> I've watched, and it never seems to load either cargo.
22:15:35 <jewoodall> Ooops. Typo. 1: Danington Mines, Full Load.
22:16:17 <jewoodall> Second line: Go to Brundinghead Woods, [far end]
22:16:20 <Yexo> can you upload your savegame somewhere?
22:18:46 <jewoodall> Okay, sent that. Thanks for the help.
22:19:08 <jewoodall> Now I'm going to try sending a single ore car, just for kicks. It wouldn't load my wood car.
22:19:41 <Yexo> jewoodall: you're missing a single piece of track hidden behind the steel mill
22:19:54 <Yexo> press x to toggle transparency
22:19:59 <Yexo> or ctrl+x to open the menu for that
22:20:13 <jewoodall> Heh. 184 pounds to fix.
22:20:21 <Yexo> after that it seems to work fine
22:20:23 <jewoodall> My guy probably lost $6,000 waiting for that.
22:21:13 <Yexo> if you want to make more money, build longer routes
22:21:18 <Yexo> your routes are all very short
22:21:49 <Yexo> brundinghead forest to weningville sawmill would be a nice length for example
22:23:06 <Yexo> setting train 1 to full load at the first station will also double the profitability of that train
22:24:33 <jewoodall> Done. Looks like train 1 is actually the bulk of my company's profit.
22:25:02 <jewoodall> I had some dumb problems in my previous games, probably solvable by means of the transparency trick you showed me.
22:25:10 <jewoodall> This was the reason for all my short runs.
22:26:00 <jewoodall> I was also amusing myself seeing if you could make "Municipal Mass Transit" into a viable business model. Frankly, I'm making it work better than most real-life cities, but it's still a waste of capital and managerial effort.
22:28:21 <Yexo> it's possible, but only profitable with bigger cities
22:28:34 <Yexo> and unmanageable even then
22:31:31 <jewoodall> I tried running freight trucking lines. Profitable like mad, but still barely manageable. I'm noticing that my train 2 is not getting adequate Wood to transport. Is it possible for a forest to disappear, as in real life?
22:33:25 <Yexo> yes, industries can close
22:33:51 <Yexo> and also distribution of cargo to stations
22:34:08 <Yexo> you'll see that it depends on station rating, which is influenced big time by always having a vehicle loading at the station
22:34:25 <Yexo> which means that for optimal production you need more than 1 vehicle per line
22:38:36 <jewoodall> Thank you. I'm trying to determine if multiple vehicles per line means more than one track. I know with Railroad Tycoon I was able to use signaling to do that, as long as there was a double section somewhere.
22:38:42 *** HerzogDeXtEr has joined #openttd
22:39:37 <jewoodall> I want to stop bothering you though and read the manual. It's not like I'm paying for a tutor.
22:40:40 <Yexo> and that is a very good mentality. If you do read the manual you're always welcome to ask any questions the manual didn't answer or you didn't found
22:40:57 <Yexo> for now you'll have to get answers from someone else though, I'm going to sleep
22:41:50 <jewoodall> Night Yexo, night all!
22:54:18 *** douknoukem has joined #openttd
23:09:04 <m> any option available which scales the control buttons?
23:09:16 <m> they're damn small on a 17'' 1920x1080 screen
23:10:04 <Ammler> m: there is biggui newgrf
23:11:20 <Eddi|zuHause> best combined with increasing font size in openttd.cfg
23:12:38 <m> and can I activate tool-tips?
23:13:08 <Eddi|zuHause> in advanced settings: either hovering x seconds or right click
23:21:31 <planetmaker> hm... maybe we should introduce a new action14 label: STAT. And such NewGRF could be offered in a separate NewGRF GUI for static NewGRFs
23:26:47 <Ammler> planetmaker: openttd should be able to detect static capable without action14
23:27:04 <Ammler> I guess, it does already
23:27:21 <Eddi|zuHause> planetmaker: no, only a button "make static", which throws an error if it's not possible
23:28:09 <Ammler> it should also make a newgrf "editable", if it is loaded on MP but static
23:30:04 <Yexo> <Ammler> it should also make a newgrf "editable", if it is loaded on MP but static <- that is not feasible
23:30:31 <Yexo> since "editing" grfs (I assume you mean adding/removing static grfs or modifying their parameters) means all grfs have to be reloaded
23:30:34 <Ammler> I fear so, because the data is in the save, right?
23:30:37 <Yexo> which is something we avoid at all cost in MP
23:30:58 <Yexo> if you want to edit them exit MP, edit static grfs, enter same game
23:31:12 <Yexo> Eddi|zuHause: for the same reason you can't make a grf static during a game
23:31:16 <Ammler> Yexo: that is something else
23:31:24 <Yexo> and before a game is started we don't know if a grf can be made static
23:31:27 <Ammler> I meant more that you could e.g. disable a static grf
23:31:31 <Yexo> as that depends also on all non-static grfs
23:31:34 <planetmaker> well... having such flag would make it easier to detect instead of testing each grf for static-ness
23:31:39 <Yexo> Ammler: that is exactly the same
23:31:55 <Ammler> Yexo: a static grf, which is loaded on MP
23:31:59 <Yexo> planetmaker: you can't test a grf for staticness without having a list of grfs that will be active
23:32:10 <Yexo> Ammler: a server has no static grfs
23:32:12 <planetmaker> Yexo: but a14 is read before
23:32:16 <Yexo> that would be rather pointless
23:32:25 <planetmaker> that's why I suggest(ed) the a14 additon
23:32:31 <Yexo> planetmaker: yes, but you can't take the value from a14 as authority, jsut as hint
23:32:31 <Ammler> Yexo: you can load every static grf as normal grf
23:32:34 <Eddi|zuHause> planetmaker: what yexo means is a grf cannot be made static if another grf references it
23:32:39 <Yexo> planetmaker: I'm not saying that's a bad suggestion
23:32:49 <Yexo> Ammler: if you do it's no longer a static grf
23:32:54 <planetmaker> Yexo: yes, I know that authors can mess up.
23:33:03 <Yexo> a static grf is only static as long as it's statically loaded, ie not by the server
23:33:08 <planetmaker> But it could give a list of newgrfs which one could filter for
23:33:09 <Yexo> nothing is going to change that
23:33:17 <Yexo> planetmaker: <Yexo> planetmaker: I'm not saying that's a bad suggestion
23:33:21 <Yexo> in fact I rather like it
23:33:44 <Eddi|zuHause> Ammler: you can make a counter-grf
23:34:04 <planetmaker> I'm not trying to contradict you, Yexo :-)
23:34:07 <Eddi|zuHause> that reverses the effect of certain known static-able grfs
23:34:23 <planetmaker> I mainly wonder how a 'bigGUI' could be provided
23:34:41 <Yexo> Eddi|zuHause: impossible, static grfs are always loaded after the normal grfs
23:34:46 <planetmaker> And actually everything would be solved, if both, a) fonts are GUI-configurable and static GUI-grfs.
23:35:03 <Ammler> planetmaker: they don't need action14 to be so
23:35:27 <Eddi|zuHause> Yexo: i understand it like Ammler wants to disable a grf that is loaded on the server, that has only static-like effects
23:35:28 <Yexo> Ammler: but that would make it easier for the user to filter which grfs might be safe for static use
23:35:40 <Yexo> Eddi|zuHause: that will never be supported
23:35:58 <planetmaker> doesn't make sense either, I think
23:36:01 <Eddi|zuHause> Yexo: yes, hence my suggestion
23:36:04 <Ammler> Yexo: yes, but openttd could "flag" the grfs on loading
23:36:14 <Ammler> so you can be sure, it is really static
23:36:19 <Yexo> Eddi|zuHause: ah, a local static grf that reverses the effects
23:36:30 <planetmaker> Ammler: not really. Another grf could depend on it
23:36:31 <Yexo> Ammler: as I said before, that's impossible
23:36:42 <Ammler> Yexo: openttd does that already
23:36:51 <Ammler> just add all newgrfs to static
23:36:54 <Yexo> you can't know whether a grf is safe for loading as static grf before you have a list of active newgrfs
23:37:00 <Ammler> then all non-static will automatically be dropped
23:37:03 <Yexo> Ammler: no, it flags certain grfs as "unsafe" for static
23:37:10 <Yexo> that is something else than flagging the rest as "safe for static"
23:37:26 <Eddi|zuHause> anyway, the main problem is there is no GUI for making a grf static
23:37:35 <Eddi|zuHause> that's what i intended to solve
23:37:37 <planetmaker> *sigh* yes, exactly, Eddi|zuHause
23:37:53 <planetmaker> you're working on it?
23:38:00 <Ammler> well, at least it worked that way back '.5/0.6 as I we made grfpack static list
23:38:11 <Eddi|zuHause> i'm never working on GUI :p
23:38:20 <planetmaker> [01:37] Eddi|zuHause that's what i intended to solve
23:38:31 <planetmaker> sounds like, though ;-)
23:38:32 <Eddi|zuHause> planetmaker: with my suggestion of a button
23:38:50 <planetmaker> where should that be?
23:39:11 <Eddi|zuHause> in the newgrf gui
23:39:42 <planetmaker> I wonder whether static NewGRF should be configurable from e.g. the options menu
23:39:44 <Ammler> Yexo: what is the difference of "1. all grfs are static, 2. drop the unsafe" and "scan for static grfs"?
23:39:46 <Eddi|zuHause> maybe next to the "add" button
23:40:31 <planetmaker> Eddi|zuHause: what I can envision there as an easy change is a mode switch static vs. standard
23:40:39 <Yexo> Ammler: "scan for static grfs" implies that you can be sure whether a grf is safe to be loaded as static. The first approach means you start with all grfs and drop the known unsafe ones, resulting in a list with grfs which _might_ be safe for static
23:40:44 <planetmaker> thus that two independent list of grfs are handled
23:41:22 <Eddi|zuHause> Yexo: i disagree, a preliminary check for static-ability need not be exact
23:41:23 <planetmaker> Yexo: 'scan for static' implies to actually read each grf entirely, right?
23:41:28 <Ammler> Yexo: how can action14 make that better?
23:41:31 <planetmaker> something which is not done by default
23:41:49 <planetmaker> Eddi|zuHause: that's why I suggested the a14 property
23:41:53 <Ammler> how should a author better know, which grf is safe, which not
23:41:55 <Yexo> Ammler: by having non-static grfs that might not be automatically detected as unsafe mark themself as unsafe
23:42:01 <planetmaker> it need not be exact. But should be a pretty good hint
23:42:47 <Yexo> let's drop this discussions, the important part is the gui
23:43:04 <Yexo> I think we more or less agree on the rest, apart from maybe some semantics
23:43:05 <Eddi|zuHause> planetmaker: problem of an a14 entry is that grf authors will misunderstand what it does, and set it in wrong cases
23:43:28 <Yexo> Eddi|zuHause: action14 is only hints anyway, it can never be used as final grf info
23:44:07 <Ammler> you do already e.g. with version
23:44:08 <planetmaker> thus "as a default filter" so that I don't have to browse through 400 static unsafe newgrfs
23:44:12 <Eddi|zuHause> Yexo: yes, but the info gets worthless then, might as well not have it at all
23:44:39 <Yexo> planetmaker: question is how large that list is after removing all grfs with action3 / etc.
23:44:42 <Yexo> which are known to be unsafe
23:45:06 <planetmaker> is that known upon normal scan?
23:45:09 <Eddi|zuHause> planetmaker: but an a14 entry also does not help with older grfs
23:45:32 <planetmaker> I'm not sure I want to extend the grf scan even more...
23:45:36 <Ammler> planetmaker: add all newgrfs to static then start openttd
23:46:02 <Ammler> it does automatically drop the unstatic
23:46:39 <Ammler> that is how I made the static list for the grfpack until we dropped static support
23:51:07 <Ammler> the grfpack has scripts to make a list for cfg :-)
23:52:52 <Yexo> Ammler: if A.grf checks whether B.grf is active, than B.grf is static-unsafe if A.grf is loaded non-static
23:53:05 <Yexo> if A.grf is loaded static or not at all then B.grf can still be static-safe
23:54:08 <Ammler> good example is dutch catenary and canadian statins
23:54:57 <Ammler> but I thought, frosch fixed that
23:55:14 <Yexo> planetmaker: that code is only reached during actual processing of the grfs, not during the pre-scan stage
23:55:24 <Yexo> Ammler: that's impossible to fix
23:55:33 <Yexo> unless you want to break the existing spec and create a new one
23:55:36 <planetmaker> yes, I'm searching that still
23:55:46 <Ammler> Yexo: well, disabling the grf
23:56:06 <Ammler> but not sure anymore, very long ago
23:56:30 <Yexo> anyway, now it's really time to sleep
23:56:59 <Eddi|zuHause> afair the fix was to disable dutch catenary instead of canadian stations
23:57:10 <Ammler> Eddi|zuHause: yes, the static grf
23:59:51 <Ammler> Eddi|zuHause: or do you mean, the grf author fixed it?
continue to next day ⏵