IRC logs for #openttd on OFTC at 2011-03-27
⏴ go to previous day
00:04:39 *** supermop has joined #openttd
00:47:41 <confound> sometimes with PBS I will find trains stopping when they don't really need to, e.g. in front of a large station or a complex junction, and they'll say "waiting for free path" even if a path seems obviously free (I have "show reserved tracks" on)
00:47:55 <confound> any idea why? a quick forum search shows nothing, but I'm not sure I'm searchin for the right terms
00:58:20 <Markk> confound: What I can think of is that the train may be lost.
01:00:26 <Eddi|zuHause> AN HOUR JUST WENT MISSING!
01:04:55 <confound> Markk: trains regularly go through these junctions without getting lost
01:05:24 <confound> I tried adding a waypoint not long after the junction and it didn't seem to help, too.
01:05:54 <Markk> And other trains can find the same station?
01:06:50 <confound> and it's not a particular train that always stops
01:20:17 <Eddi|zuHause> confound: maybe it is trying to find a depot?
01:21:37 <Eddi|zuHause> confound: also, pathfinder penalties may guide your trains through tracks you wouldn't immediately choose by yourself
01:23:20 <confound> it's not trying to find a depot, though that was a good idea
01:23:25 <confound> what do you mean about pathfinder penalties?
01:23:48 <confound> the trains end up getting to the right place
01:26:35 <confound> and there are a bunch of trains before and after, with the same orders, that don't seem to have any problem taking whichever track is free
01:26:54 <confound> (this particular one is a 2 line + 2 line -> 2 line merge)
01:29:31 <Eddi|zuHause> confound: i mean: the track ahead gets differently favourable values depending on where there are track reservations further ahead than one signal block. in those cases, a train may decide to take the track that is blocked, instead of the one that is free.
01:30:27 <confound> so maybe it thinks the blocked track is really just that much better
01:30:36 <Eddi|zuHause> each track tile gets a calculated penalty (low for a free track, higher for occupied track, stations, level crossings, etc.)
01:31:01 <Eddi|zuHause> the path that adds up to the lowest over its entire length gets chosen
01:31:30 <confound> so, moving the waypoint I have to immediately after the junction might help?
01:31:41 <confound> because it will be pathfinding for a very short distance and have less potential confusion
01:31:58 <Eddi|zuHause> yes. but too close could have other negative effects
01:33:15 <Eddi|zuHause> there are certain load balancing features built in, which will lose their effect completely
01:33:43 <confound> well, in this case I don't really want any load balancing -- I just want to pick the free track
01:33:48 <confound> the immediately free track
01:33:50 <Eddi|zuHause> so you might get one line too tightly packed, and at later merges you don't find enough openings, while the other track will be almost empty
01:34:22 <confound> oh, I guess it will still affect what happens when both lines are free
01:34:42 <confound> is there anywhere to read about this stuff?
01:35:00 <confound> bah. the waypoint didn't help, anyway
01:35:37 <Eddi|zuHause> but there might be a valid suggestion here: apply different penalty for reserved track in the signal block directly ahead
01:36:16 <confound> than for reserved track further on?
01:37:07 <Eddi|zuHause> for block signals, only the next 10 signals are considered, all other signals are ignored
01:38:55 <confound> these are entirely PBS
01:39:07 <confound> does that change anything about what you said?
01:40:35 <Eddi|zuHause> i meant: for block signals, it is really a local balancing effect, so there need to be measures to make it similar for path signals
01:47:14 <confound> I guess I could crank up pf.yapf.rail_pbs_cross_penalty and see if that helps
01:51:04 <Eddi|zuHause> playing with that may make it better. or make it worse. the highest probability however is, that you screw up your network at a completely differenent place
01:53:37 <confound> turning random knobs isn't my favorite way to try to solve a problem
02:08:37 <confound> anyway, thanks. I might just try to find another way to join these tracks
02:11:45 *** DanMacK has joined #openttd
03:19:51 *** Dreamxtreme has joined #openttd
04:56:22 *** Eddi|zuHause has joined #openttd
04:57:16 *** Markavian has joined #openttd
05:05:18 *** bryjen_ has joined #openttd
05:23:59 *** varbles has joined #openttd
05:24:12 <varbles> didnt know you guys had an irc channel
05:29:50 <planetmaker> someone stole an hour while I was sleeping :S
05:30:42 *** roboboy has joined #openttd
06:16:15 *** HerzogDeXtEr1 has joined #openttd
06:18:51 <varbles> will 1.0.5 allow us to continue a game started in 1.0.03
06:20:49 *** sla_ro|master has joined #openttd
07:10:11 *** andythenorth has joined #openttd
07:30:05 <planetmaker> varbles: you can continue every game in a newer version. But usually not with an older version
07:37:30 *** Kurimus has joined #openttd
07:46:37 *** ar3k is now known as ar3kaw
07:57:09 *** |Jeroen| has joined #openttd
08:39:43 *** Alberth has joined #openttd
08:39:43 *** ChanServ sets mode: +o Alberth
08:52:49 *** Progman has joined #openttd
08:57:41 <andythenorth> for me I get up at the same baby-related time anyway
08:57:48 <andythenorth> it just means everyone else appears one hour earlier :P
09:03:52 *** Cybertinus has joined #openttd
09:19:01 *** JOHNSHEPARD has joined #openttd
09:28:16 *** Devroush has joined #openttd
09:31:56 *** amkoroew has joined #openttd
09:37:31 * andythenorth tests an alternative cargo scheme against UKRS 2
10:32:20 *** KenjiE20 has joined #openttd
10:59:51 * andythenorth tries again to understand cargo classes
11:14:43 *** frosch123 has joined #openttd
11:15:35 * andythenorth wonders how much cargo improvement could be achieved with minimal spec
11:17:45 <Yexo> the changes to the spec are not the problem, the changes to all vehicle sets are way more problematic'
11:30:16 <andythenorth> I think there's a way that works with existing sets
11:30:25 <andythenorth> keeping (train) prop 28 as is
11:30:50 <andythenorth> allowing cargos three new props for OR, AND, NOT classes
11:31:05 <andythenorth> and ignoring (train) prop 29 when the cargos provide the new props
11:31:10 <andythenorth> existing sets just carry on
11:31:44 <andythenorth> by my initial test of mapping, sets that break badly were using classes wrong
11:32:08 <andythenorth> I don't know how to express the logic
11:32:23 <andythenorth> my understanding of logic never seems to go >50% :(
11:33:40 <andythenorth> I think it would mean no changes to vehicle props at all
11:34:44 *** Aylomen has joined #openttd
11:39:44 <andythenorth> three cargo props would be needed, logic (I think would be)
11:39:55 <andythenorth> allow refit IF ((class 1 OR class 2) AND class 3 NAND class 4)
11:40:13 <andythenorth> ((class 1 OR class 2) AND class 3) NAND class 4
11:41:07 <andythenorth> even then, I'm not sure that's correct :|
11:41:56 <andythenorth> that would allow refit if class 4 true and not classes 1, 2 or 3
11:42:33 <andythenorth> ((class 1 OR class 2) AND class 3) AND NOT class 4
11:51:12 <frosch123> andythenorth: just to throw in my default concern: don't you think a callback checking some variables is a lot easier than 3 or 4 properties with complicates AND, OR; XOR and more?
11:57:32 <andythenorth> frosch123: maybe
11:57:48 <andythenorth> I hesitate to propose that
11:57:58 <andythenorth> but I can see how it might be cleaner
11:58:22 <andythenorth> and logic moves to the newgrf author
12:02:26 *** Intexon has joined #openttd
12:03:06 <andythenorth> frosch123: ok, it's a good idea
12:03:25 <andythenorth> one new callback, allow refitting. Return 00 80 or 01 80 to allow / disallow
12:03:40 <frosch123> you could also return some capacity multiplier
12:04:01 <andythenorth> train props 28 / 29 are already available (and equivalent for other vehicles)?
12:04:43 <andythenorth> and I can identify which newgrf a vehicle is from
12:04:57 <frosch123> all properties are available. but i would avoid calling cb 36
12:05:06 <frosch123> i.e. avoid properies which can be modified via cb 36
12:05:07 <andythenorth> so authors, if they could be bothered, could special case for old, no-longer maintained vehicle sets
12:05:21 <andythenorth> is this something that could be tested?
12:05:44 <andythenorth> a new callback :)
12:06:44 <andythenorth> this is called on the cargo, not the vehicle, yes?
12:06:46 <frosch123> well, i suggested a refit cb for vehicles some time ago (also quoted yesterday). but maybe you are right that a cargo callback would be better
12:07:05 <andythenorth> I think that vehicles the existing system is effective
12:07:14 <andythenorth> as there is always the possibility of labels
12:07:22 <andythenorth> and class handling by cb won't be much better than is already available
12:07:46 <andythenorth> and I have a strong feeling it was designed for certain needs of certain vehicle authors in any case
12:08:17 <frosch123> andythenorth: you could add something like: cb is not called for cargos which are part of the cargo trans table of the grf
12:08:31 <frosch123> i.e. "known to the vehicle grf"
12:08:38 <frosch123> but, i am not sure about that
12:08:43 <andythenorth> this is an interesting point
12:09:48 <andythenorth> isn't it more that prop 1D should be respected?
12:10:41 <frosch123> well, but you cannot tell properly from prop 1d whether a cargo is explcitly wanted or unwanted
12:12:12 <andythenorth> do vehicle authors need to be able to over-ride a cargo cb for refittability?
12:12:25 * andythenorth tries to think of a case for that
12:12:57 <andythenorth> if the refitting is wrong, the classes are wrong
12:13:00 <frosch123> if a vehicle grf knows a specific cargo, it should know better :)
12:13:52 <andythenorth> assuming that cargos remain consistently defined between sets
12:13:57 <andythenorth> so far we've managed that quite well
12:14:20 <andythenorth> there is only one point of difference between ECS and FIRS which irritates
12:15:39 <andythenorth> otherwise we agree pretty well
12:16:48 <andythenorth> but I think over-riding the cb would limit the usefulness
12:16:57 <andythenorth> sand is a good case
12:17:23 <andythenorth> try, without using explicit support, to define sand to allow it to travel in open wagons, open hoppers, and covered hoppers
12:17:31 <andythenorth> whilst also preventing coal from travelling by covered hopper
12:18:12 <andythenorth> using the existing vehicle props
12:18:38 <andythenorth> using a cargo cb, and existing classes, it's easy
12:18:51 <st6> how can i see what server am i in? =)
12:20:14 <Eddi|zuHause> quit and look at the last server you were in.
12:20:35 <Alberth> ask the ingame chat :p
12:20:54 *** andythenorth_ has joined #openttd
12:21:05 *** andythenorth has joined #openttd
12:21:27 <frosch123> st6: open console and type "list_settings network"
12:21:31 <frosch123> maybe the information is in there
12:21:45 <frosch123> last_host and last_port probably
12:26:06 <andythenorth> frosch123: what's the worse that could happen if we ship a new cb?
12:29:05 *** JOHN-SHEPARD_ has joined #openttd
12:33:15 <frosch123> andythenorth: the world could end?
12:33:33 <frosch123> it just needs to be consistent and predictable :)
12:33:34 <andythenorth> I was looking for odd cases
12:33:47 <andythenorth> cases like 'how does Pikka support a grain-only wagon'
12:34:05 <andythenorth> and the answer appears to be 'explicit support using train prop 1D, not classes'
12:34:23 <andythenorth> far as I can tell
12:34:37 <frosch123> a grain only car would set all class properties to 0 and only use 1D
12:35:07 <andythenorth> the thing I like about the scheme I worked out was that it doesn't change existing classes in any way
12:35:13 <frosch123> if a cargo grf forces the refittability to a certain cargo, while refittable-classes is zero, that is the fault of the cargo grf
12:35:30 *** Eddi|zuHause has joined #openttd
12:35:32 <frosch123> otoh, what's wrong if the cargo grf says: everything refittable to grain is also refittable to maize
12:36:02 <andythenorth> means cargo grfs can get support from legacy sets by saying 'treat this cargo like this other cargo'
12:36:27 <andythenorth> neither classes nor labels enable that quite as much as they might
12:37:04 <andythenorth> frosch123: is this a complex cb to write?
12:37:17 <frosch123> can't say without a spec :)
12:37:23 <andythenorth> shall we write a spec :P
12:37:33 <frosch123> might be a start :p
12:37:40 <andythenorth> the multiplier idea...
12:37:47 <andythenorth> what does it do / is it needed?
12:39:17 <frosch123> it could be handy for light cargo
12:40:16 <andythenorth> I'm often confused by the weight / units distinction
12:40:30 <andythenorth> e.g. some vehicles treat a crate of goods as 0.5t
12:40:35 <andythenorth> some treat it as 1t
12:40:42 <andythenorth> this I find puzzling
12:47:44 *** glevans2 has joined #openttd
12:49:03 <Alberth> in OpenTTD, gravity is not constant
12:55:18 <SpComb> then why are cargo weights not in newtons? :(
12:56:40 <Rubidium> because then we'd have to discuss whether it's newtonnes, short newtons, long newtons and such
13:04:58 *** Biolunar has joined #openttd
13:21:16 <frosch123> andythenorth: the cb would be called on loading/starting the game
13:21:31 <frosch123> refittability needs to stay constant during a game, or bad things may happen :p
13:21:53 <frosch123> however, it could also be called on refitting, to set the multipliers or so
13:22:18 <andythenorth> so you think 'refit to x before 1982 and y after 1982' is bad gameplay :P
13:22:54 <andythenorth> so the implementation has to cache all vehicle refittability somewhere?
13:24:41 <Eddi|zuHause> "*** In Bielefeld (ha!) findet übrigens am 1. April (haha!) in der Hechelei (haha, hu, das ist echt nicht mehr witzig) die eins!elf!Fte Verleihung der Big Brother Awards Deutschland statt."
13:31:47 <andythenorth> frosch123: would the cb need enabling explicitly?
13:33:22 <andythenorth> just wondering for the spec
13:35:03 <frosch123> what variables does it need?
13:35:23 <frosch123> i guess the two cargo class properties
13:35:25 <andythenorth> (I'll refer to train props if that's ok)
13:35:40 <frosch123> most props are useless :)
13:36:13 <andythenorth> everything relating to consists is pointless / dangerous at this point...
13:36:44 <frosch123> you cannot access the consist, there is not even a vehicle
13:36:57 <andythenorth> and if you could...that would be nuts
13:36:59 <frosch123> it is called on game load/start, so you have only the purchase list information
13:37:34 <frosch123> and exposing cb36 properties is also bad
13:37:39 <andythenorth> would a newgrf id and vehicle id be safe?
13:38:06 <andythenorth> I'm not sure whether to limit potential for bad behaviour or not
13:38:24 <andythenorth> e.g. with date vars, cargo cargo authors could do stupid things
13:38:39 <andythenorth> checking date would be broken
13:38:44 <Eddi|zuHause> <andythenorth> so you think 'refit to x before 1982 and y after 1982' is bad gameplay :P <-- you can already do that with introducing a new vehicle, it doesn't need a refitability callback.
13:39:04 <andythenorth> but it would be very bad behaviour by a cargo set author
13:39:07 <andythenorth> unless it's a prank
13:39:53 <andythenorth> if dates were available, some well-meaning person will try and use them to 'hide' cargos until they're available
13:39:56 <andythenorth> and other such confusing things
13:40:44 <andythenorth> frosch123: essential: prop 28 / 29
13:40:53 <andythenorth> maybe 1D, but I can't see how to trust it
13:41:00 <andythenorth> and ideally grfid and vehicle id
13:41:25 <andythenorth> everything else should be forbidden unless we think of a good reason for it
13:42:10 <Eddi|zuHause> if you say something like "Maize is the same as Grain", then that essentially works the same as railtype compatibility
13:42:22 <andythenorth> but I think 1D is needed for that
13:42:29 <andythenorth> and 1D can't be trusted
13:43:38 <Eddi|zuHause> but that essentially makes cargo classes kind of "similar to <existing cargo>", it's not possible to create entirely new cargo classes that are not covered yet
13:46:49 <frosch123> you could add a 60+ variable which takes a cargo as parameter, and returns the current refittability or so
13:47:26 *** Ruudjah has joined #openttd
13:50:46 <andythenorth> frosch123: where would that be used?
14:01:23 <frosch123> and you can do the grain -> maize thingie
14:02:48 <andythenorth> yes that would be very useful
14:04:21 <andythenorth> with this, I could, for example, provide full FIRS support for US Set
14:04:39 <andythenorth> that could be done now with adapters and action 6, but that would be a headache
14:04:52 <andythenorth> this way I could map most new cargos onto older known cargos
14:05:14 <andythenorth> it's a lot of work for me, but acceptable
14:07:42 <andythenorth> with branching varact 2, quite nice degrading support could be provided
14:09:07 * andythenorth is going to the park and will be back later
14:14:20 <Eddi|zuHause> crazy idea: this could also be used for "cargo 'Sand' looks like cargo 'Grain', so use the same graphics [if not handled directly]"
14:15:21 <Yexo> not possible if the grf determines the graphics to use via a varaction2 chain
14:15:44 <Eddi|zuHause> yes, but possible if they decide cargo graphics in the action 3
14:16:10 <Yexo> how many grfs actually do that?
14:34:11 <Ammler> omg, you really added .ini files :-o
14:35:11 <Ammler> why aren't those cfgs?
14:35:37 <Eddi|zuHause> describing "format X" by using "format X" is a traditional computer science task ;)
14:38:25 <Alberth> it is not a config file but rather a source file?
14:40:07 <Eddi|zuHause> Ammler: the extension "cfg" is rather describing the content, not the format
14:40:36 <Ammler> the cfg isn't ini format
14:40:50 <Ammler> maybe that has changed
14:41:48 <Eddi|zuHause> Ammler: let's call it a dialect.
14:42:01 <Ammler> Alberth: I see, the ini is just needed to build?
14:42:35 <Eddi|zuHause> Ammler: the ini files have the same stuff that was previously in settings.h
14:42:35 <Alberth> Eddi|zuHause: in fact, every INI file is a dialect, there is no official definition of the format
14:43:07 <Eddi|zuHause> Ammler: settings.h is now autogenerated from those files
14:43:29 <Ammler> well, at least php ini parser wasn't able to read/write openttd.cfg
14:44:19 <Ammler> iirc, specially the part with newgrfs
14:44:19 <Rubidium> what makes php's parser right?
14:44:23 <Alberth> not a surprise, given the lack of standardization :)
14:44:36 <Eddi|zuHause> Ammler: that was because of missing = at the end, right? i think that was fixed later
14:45:11 <Alberth> I am quite sure a lot of INI file readers will not read the new settings either
14:45:44 <Alberth> since section names are not unique
14:47:14 <Ammler> Alberth: not possible to split settings.ini in multiple files, so e.g. patches could have their own ini file?
14:48:17 <Eddi|zuHause> patch settings need an own chunk, for better savegame compatibility
14:48:17 <Ammler> hmm, patching seems not the reason for the change :-)
14:49:09 <Eddi|zuHause> that, or the settings must be stored in the savegame by name, and invalid settings ignored
14:49:55 <Eddi|zuHause> the case that a patch needs bumping the savegame version just for adding a setting needs to be avoided
14:50:21 <Eddi|zuHause> then only real changes like cargodist or heightlevels need bumping savegame version
15:03:18 <Rubidium> and they would be able to join normal server
15:10:11 <Eddi|zuHause> Rubidium: no, why would that have anything to do with savegame version?
15:15:43 <Rubidium> the M doesn't necessarily get added, making joining work just fine
15:16:07 <Eddi|zuHause> Rubidium: i'm not worried about multiplayer, i'm worried about long term compatibility of savegames. once a savegame was touched by a patch, it is currently almost impossible to get it compatibile with future trunk again
15:16:10 <Rubidium> and then we'll be getting the unreproducable desync reports
15:16:58 <Eddi|zuHause> Rubidium: meaning lots of people stay away from patches, because they can't use their savegames afterwards
15:17:26 <Eddi|zuHause> the hurdle of losing savegame compatibility for one single setting is too high
15:18:20 <Rubidium> how many people actually run (simple) patched binaries?
15:18:37 <Eddi|zuHause> Rubidium: too few, that's what i'm talking about.
15:18:58 <Rubidium> and how many would be using cargodist/heightlevels/whatever patch needs savegame bumps anyway?
15:19:34 <Rubidium> i.e. how many of the patch users are not patchpack/cargodist users?
15:19:39 <Eddi|zuHause> Rubidium: that's a "don't care" for this consideration
15:20:51 <Eddi|zuHause> i'm talking about little things like "show town rating in name" or some variants of daylength
15:21:32 <Rubidium> show town rating in name => gui setting => does not need to modify savegame
15:21:37 <Eddi|zuHause> it would be fairly trivial to move these savegames back and forth, but it's blocked by the setting handling
15:22:11 <Rubidium> daylength on the other hand seems to be changing some value in any case
15:22:17 <Eddi|zuHause> maybe that wasn't the right example. but there are lots of patches which only modify savegame version because of a setting
15:22:34 <Rubidium> e.g. the fractional day
15:23:16 <Eddi|zuHause> Rubidium: i have been using a modified daylength with only changing the setting to non-stored for a long time
15:24:12 <Eddi|zuHause> that is the only way to keep it compatibile through trunk updates
15:24:26 <Eddi|zuHause> and daylength games tend to be long term
15:24:58 <Rubidium> you can, ofcourse, add the setting and such into a new chunk
15:25:37 <Eddi|zuHause> yes, and i was proposing that openttd prepares that new chunk, so a patcher only needs to fill out the file
15:26:03 <Rubidium> problem is, that if OpenTTD encounters a chunk it assumes it's from an unknown patched version and refuses to load it
15:26:51 <Rubidium> and we actually used that behaviour to our advantage to fix some bugs in stable branches
15:27:48 <Eddi|zuHause> Rubidium: that need not change. as far as i understand what you are saying
15:27:50 <Rubidium> "marking" the newer stable savegames as unloadable by older stables (of the same branch), while retaining the ability to load all stables without loss of information into trunk
15:28:17 <Rubidium> ergo: adding a chunk will still make the savegame unable to load in newer trunk versions
15:28:48 <Eddi|zuHause> Rubidium: the main scenario i am talking about is keeping alive a patch through an "svn up" which currently often conflicts on savegame version
15:29:32 <Eddi|zuHause> which means you lose either your patched savegame, or compatibility with savegames from newer trunk
15:29:44 <Rubidium> if you change the savegame version to $version + 1, then svn up will not cause a conflict
15:29:48 <Eddi|zuHause> a new chunk would avoid that
15:29:57 <Rubidium> unless we bumped it twice already in trunk
15:30:14 <Rubidium> the rest should just merge fine with subversion
15:30:28 <Eddi|zuHause> Rubidium: it needs more than that
15:30:50 <Eddi|zuHause> Rubidium: lots of patchers stay away from this concept, because it is too complicated to maintain
15:31:37 <Eddi|zuHause> Rubidium: someone writing a patch has more important things to think about than that
15:31:40 <Rubidium> as if a: chunk that will be ignored, but for which you have to write your own saveload code will make it any better
15:32:47 <Rubidium> but oh... it won't be ignored in trunk, which you based your patch off... so it will be ignored in your version as well
15:32:51 <Eddi|zuHause> Rubidium: that's why i say trunk should prepare everything, the patcher just needs to add his setting to patches.ini
15:33:32 <Eddi|zuHause> Rubidium: in case the patch gets merged, the lines from patches.ini will go into settings.ini instead
15:33:44 <Rubidium> and the savegame is lost as well
15:34:24 <Eddi|zuHause> Rubidium: but that is a single case, instead of every trunk update.
15:34:47 <Eddi|zuHause> it can be handled somehow
15:35:33 <Rubidium> but then OpenTTD has to not ignore savegames from patched binaries
15:35:41 <Eddi|zuHause> Rubidium: someone who has patched savegames can then try to load his savegame into a modified trunk which ignores the patch-section
15:35:42 <Rubidium> so that can't be handled
15:36:11 *** DayDreamer has joined #openttd
15:36:33 <Eddi|zuHause> Rubidium: that's a "simple" patch in this case
15:36:52 <Eddi|zuHause> which not even the patch author must write himself
15:37:14 <Eddi|zuHause> as the same patch will work for any such additional setting
15:37:40 <Eddi|zuHause> could even be a ./configure option
15:40:31 <Rubidium> and how will it work when you add more settings?
15:40:44 <Rubidium> or remove settings from that "patch" chunk?
15:40:56 *** Brianetta has joined #openttd
15:41:33 <Eddi|zuHause> Rubidium: that needs a little bit of thought
15:41:57 <Rubidium> I for one don't fancy writing a whole new settings saving infrastructure merely to make the live of a few of the patch users a little bit better
15:42:47 <Rubidium> after all I reckon most are using the "packs", and for them there's little to no added benefit
15:43:07 <Eddi|zuHause> Rubidium: well, the other option would be a non-linear (tree-like) savegame versioning
15:44:49 *** andythenorth has joined #openttd
15:45:19 <Rubidium> so the user can select which of the X trees it wants to save the savegame in?
15:45:48 <Rubidium> doesn't sound very feasible, as you'd end up with more and more possible savegame formats
15:46:36 *** Aylomen has joined #openttd
15:47:03 <Eddi|zuHause> Rubidium: but it would more closely depict the development in hg branches instead of a linear svn
15:48:06 <Rubidium> Eddi|zuHause: with the added bonus that the savegame version A != savegame version A, depending on the "branch" the savegame took
15:48:38 <Rubidium> which in essence means that trunk would end up with supporting loading all those development savegame versions of those patched versions
15:48:59 <Rubidium> yay savegame conversion code complexity exploding
15:49:25 <Eddi|zuHause> yes, but you can't just dismiss the use case.
15:49:52 <Rubidium> imo it's too small to warrant the maintainance nightmare
15:50:54 <Rubidium> as we would need access to the specific old patches indefinitely as well in order to reproduce the cause for some issues w.r.t. savegame loading
15:51:01 <Eddi|zuHause> Rubidium: it would allow things like cargodist, with many branches, worry about savegame compatibility of their own branch only, and on each merge, the savegame handling would handle savegames from each branch
15:51:42 <Eddi|zuHause> the savegame would know each branch version
15:52:34 <Eddi|zuHause> you couldn't load a cargodist savegame in current trunk, but you could load a cargodist savegame in a trunk after cargodist was merged
15:52:54 <Eddi|zuHause> because the savegame history was kept in that merge
15:53:10 <Rubidium> not when the important information got moved to a different chunk (patch stuff)
15:54:11 <Eddi|zuHause> i'm talking about non-linear savegame versioning here. so savegame version wouldn't be decided by one number, but by some internal tree structure
15:55:03 <Eddi|zuHause> a setting would know the tree branch it is in, and savegame updating would work along this tree branch through merges to the root
15:55:09 <Rubidium> I don't see how that would be working
15:55:24 <Eddi|zuHause> it's difficult to describe
15:56:12 <Rubidium> especially when you have dozens of branches doing savegame bumps, and dozens of savegame bumps from trunk -> hundreds, if not thousands, of different savegame versions in your tree
15:56:28 <Rubidium> or I am totally misunderstanding the proposal
15:57:14 <Eddi|zuHause> i don't think the number of savegame bumps would explode. you'd still have one bump per new setting
15:57:27 *** Kurimus has joined #openttd
15:57:39 <Eddi|zuHause> and maybe some intermediate bumps per merge
15:57:51 <Rubidium> but I guess that's a my glass ball malfunctioning; it keeps saying "dinner", and I haven't figured out how that applies to savegame versions
15:58:25 <Eddi|zuHause> maybe i should work on a draft... but that needs some time
16:13:30 *** JVassie has joined #openttd
16:35:43 *** ChanServ sets mode: +o Bjarni
16:47:39 *** verbles has joined #openttd
17:27:27 *** tokai|noir has joined #openttd
18:00:26 *** Brianetta has joined #openttd
18:01:14 *** Intexon has joined #openttd
18:03:45 *** Intexon_ has joined #openttd
18:24:07 <andythenorth> is parameters GUI in any 1.0.x version?
18:26:54 <Alberth> versions x > 0 mostly just contain backported fixes, no new features
18:27:44 <Alberth> simplest way to check is to try 1.05 :)
18:28:14 <Alberth> ie if we added it, we certainly did not remove it again :)
18:29:11 * andythenorth suspects about 25k regular players, who download content
18:29:15 <andythenorth> judging by Bananas
18:29:43 <andythenorth> but a fair proportion of those are probably churn
18:30:07 <andythenorth> either that, or I only update grfs when they're on about 25k downloads :P
18:30:19 <andythenorth> anyway, new HEQS is done
18:30:24 <andythenorth> onto the next one ;)
18:32:29 <Alberth> I should download a copy :)
18:37:10 *** Devroush has joined #openttd
18:41:29 *** verbles has joined #openttd
18:41:57 *** verbles is now known as Varbles
18:57:56 * andythenorth has a fruit and vegetable problem :P
19:01:18 <confound> andythenorth: what are the tram tweaks?
19:02:02 <andythenorth> lower loading speed
19:02:07 <andythenorth> and rebalancing of costs
19:02:41 <andythenorth> some are cheaper to run, some more expensive
19:02:54 <andythenorth> the costs for different capacity are spread over a greater range
19:03:20 <andythenorth> I was finding small slow trams made losses, whereas large fast trams made way too much profit
19:06:45 <confound> I found myself replacing a lot of smaller train lines with ishizuchis
19:10:42 <andythenorth> yeah, that's not 100% intended
19:10:53 <andythenorth> I might reduce capacity some more in future
19:19:36 <confound> one that made sense to me was a short route that handled a lot of wood
19:19:53 <confound> but it doesn't seem intentional that I should basically use them instead of trains for feeders
19:20:21 <andythenorth> they're mostly intended as an alternative to trucks
19:20:26 <andythenorth> or narrow gauge trains
19:25:46 *** fonsinchen has joined #openttd
19:31:20 *** JOHNSHEPARD has joined #openttd
19:49:14 <Eddi|zuHause> historic decision in Baden-Württemberg: Green party celebrates a landslide victory, making room for the first ever green ministerpresident
19:53:05 *** varbles has joined #openttd
19:54:21 *** andythenorth_ has joined #openttd
20:06:32 <andythenorth_> is it bed time?
20:08:05 <Bjarni> yeah andythenorth_, you should be in bed by now
20:08:19 <Eddi|zuHause> it's an hour earlier than yesterday at this time
20:08:42 <andythenorth_> it's either that, or argue some more about cargos
20:14:19 <Bjarni> Eddi|zuHause: your historical post leaves one open question.... is it a good thing? :)
20:14:50 <Eddi|zuHause> Bjarni: that is not for me to decide/forsee
20:17:09 <Bjarni> I can't decide if it's good or bad either
20:19:36 <Eddi|zuHause> it's one of those historic situations like "first woman/black/turkish/other minority"
20:20:07 <Bjarni> I don't care if it's the first woman or green or whatever
20:20:16 <Bjarni> what matters to me is the politics they stand for
20:21:20 <Bjarni> and I don't know green politics well enough to know if it's a wise move for Germany
20:27:06 <confound> andythenorth_: let's argue about cargo
20:36:31 <Eddi|zuHause> Bjarni: one key element in the politics (besides the obvious anti-nuclear position) is that the green party is against the restructuring of the Stuttgart main station, while their prospected coalition partner SPD (labour) is for these current plans
20:37:01 <Bjarni> <SmatZ> BJARNI! <--- I expected that reaction when I joined.... two hours ago
20:39:16 <Bjarni> there can be only one™
20:39:26 <Eddi|zuHause> Bjarni: these mountain people have strange expressions ;)
20:46:30 <__ln__> Bjarni: so what's up around there?
20:46:45 <__ln__> after more than a year of radio silence
20:47:14 <Bjarni> I have had it with universities and studying
20:47:20 <Bjarni> I don't want to go back there anymore
20:47:45 <Eddi|zuHause> aka you're now jobless? :p
20:48:03 <Bjarni> you really know how to ruin a good moment
20:49:10 <Eddi|zuHause> i wish you good luck ;)
20:50:10 <Bjarni> it would appear that not all companies are just like their PR shows
20:50:44 <__ln__> so you are now Master Bjarni?
20:51:16 <Bjarni> that's one way to say it
20:51:28 <Bjarni> officially it's Master of Science in Engineering
20:52:38 <Bjarni> no, but I do have optical wires
20:52:47 <Bjarni> should be fitting for a master of electronics
20:54:38 * andythenorth_ is displeased with FIRS sugar refinery
20:55:33 <andythenorth_> doesn't look good
20:56:33 <Zuu> I think I've just received the actual formal documentation of my degree. After having worked for seven months. :-)
20:57:35 <Zuu> Got a letter that I got a mail to pick from the "post office" and I suppose it is my degree.
20:58:50 <Zuu> I hope you find a good job as well.
20:59:24 <Bjarni> I ended up with my documentation when they said I would get it
20:59:26 <Eddi|zuHause> they don't deliver mail to your homes at your place?
20:59:33 * andythenorth_ has a degree somewhere
20:59:51 <andythenorth_> wonder what happened to it
21:00:06 <andythenorth_> anyway, bedtime for me
21:00:12 *** andythenorth_ has left #openttd
21:00:19 <Eddi|zuHause> degrees tend to gather dust right after you get an actual job.
21:00:20 <Bjarni> it did get a little delayed because somebody objected that I failed to meet the demands for graduation and I had to work to prove that she made a mistake and everything is ok
21:00:32 <__ln__> Eddi|zuHause: maybe it's the kind of ... registered mail that needs to be picked up personally with an ID
21:00:47 <Zuu> They delever mail to homes here, but this is a more secure kind of mail that you have to go and pick up yourself.
21:01:17 <Eddi|zuHause> but they could check the ID at your place as well
21:01:32 <Bjarni> yeah but they usually need a signature for delivery
21:01:50 <Bjarni> and if nobody is at home when the mailman shows up, then you have to go pick it up
21:01:53 <Eddi|zuHause> signature is way more common than ID
21:01:56 <Bjarni> works the same way here
21:02:56 <Eddi|zuHause> signature can also be given by neighbours in some cases
21:03:33 <Bjarni> but it can be given by somebody else in the household
21:04:14 <Eddi|zuHause> this is common for packets here. the recipient will get a letter in his mail that the neighbour picked up the packet
21:04:16 <Bjarni> or at least they seem to accept it
21:05:07 <Zuu> Eddi|zuHause: Then you're good neighbours
21:05:46 * Bjarni wonders if it works like that in Queens
21:05:46 <Zuu> I don't think that would happen here, at least not in the cities. Maybe in the countryside where people actually might know their neighbours.
21:06:45 <Eddi|zuHause> that's quite possible that it's less common in cities
21:06:59 <__ln__> if i got the papers of a degree by mail, i wouldn't want that to be handed to a random neighbor
21:07:20 <Eddi|zuHause> __ln__: it's illegal to open these.
21:09:55 <Bjarni> illegal..... so is speeding
21:10:04 <Bjarni> yet it happens all the time
21:10:46 <Eddi|zuHause> actually, speeding is just a finable offense, while opening other's mail is a punishable offense
21:11:44 <Eddi|zuHause> the german term is "ordnungswidrig" vs. "gesetzwidrig"
21:11:51 <Bjarni> so many crimes ends up unsolved
21:12:15 <Bjarni> or unable to go to court due to some silly issue
21:12:23 <Eddi|zuHause> Bjarni: this is easily solved, since it is recorded who picked up the packet
21:12:45 <Bjarni> some guy in Denmark appears to have made a hit-and-run with his car
21:13:02 <Bjarni> he ended up not having to go to court..... because his sister doesn't live with him
21:13:16 <Bjarni> but was present in his home when the police arrived
21:14:48 <Eddi|zuHause> Bjarni: that's just because successfuly solved and punished offenses are not in the news.
21:17:13 <Bjarni> like the other day they spent a great deal of time talking about a demonstration against military actions in Libya.... and it turned out to be a one man demonstration, but they failed to tell that
21:18:14 <__ln__> you didn't get anyone else to demonstrate with you?
21:20:45 <__ln__> Bjarni: will you attend the r30000 party?
21:29:27 <Bjarni> <__ln__> you didn't get anyone else to demonstrate with you? <--- LOL
21:30:04 <Bjarni> it was some freak who thought nobody would get killed in Libya if nobody from other countries showed up
21:32:21 <Eddi|zuHause> if it weren't "super election year", germany would probably take part in libya
21:33:44 <Bjarni> you know people didn't really think it was a nice move for Germany not to join
21:33:58 <Eddi|zuHause> maybe some back-room strategist calculated "hmm, when Schröder in 2002 rejected taking part in iraq, he won the election right afterwards, maybe rejecting now will work again"
21:33:59 <Bjarni> the decision was a historical one in Denmark
21:34:28 <Bjarni> the news showed the votes in parliament.... 0 against
21:34:41 <Bjarni> even the pacifistic red ones votes yes
21:35:23 <Eddi|zuHause> when things like afghanistan come up for vote in parliament, only few people are against it...
21:35:37 <Bjarni> but only after they had a written promise that their vote would not be used to target civilians..... which just shows they live in their own world
21:35:38 <Eddi|zuHause> it has to be decided every year
21:35:54 <Eddi|zuHause> presence in afghanistan, or even in bosnia...
21:37:34 <Eddi|zuHause> note that libya wasn't even up for vote, it was directly decided by the government not to even think about it.
21:41:20 <Eddi|zuHause> (current federal government is a coalition of CDU [christian, outside bavaria], CSU [christian, bavaria only] and FDP [liberal])
21:46:24 <Eddi|zuHause> (reason for the proposal is the explosion of costs)
21:48:11 <Zuu> Hmm, silly HP software update decided to reboot my computer :-(
21:48:29 <Ammler> then you use windows :-)
21:48:33 <Eddi|zuHause> that's why i stopped using windows.
21:48:50 <__ln__> maybe you should only stop using HP
21:49:20 <Ammler> how much annoying experience do you need for the switch? :-P
21:49:26 <Zuu> I got a home built lound monster I could use instead.
21:50:05 <Zuu> I've used only Linux for about 3 years of my life.
21:50:17 <Zuu> At the beginning of my university studies.
21:50:45 <Zuu> But it become too much micro management.. :-)
21:50:50 <Ammler> nah, then you didn't use it, you can't go back to windows if you would have used
21:51:55 <Zuu> I found myself spending too much tweaking my Linux desktops.
21:53:12 <Zuu> But the final thing was that I couldn't get my wacom I to work in dual screen mode (spanning over both screens).
21:54:12 <Zuu> But now that I got a 24" wide screen instead of two 4:3 screens, I don't have that argument anymore. :-)
21:57:09 <Eddi|zuHause> i guess cinerama would have improved meanwhile as well ;)
21:57:37 <Bjarni> <Zuu> I found myself spending too much tweaking my Linux desktops. <--- I noticed this problem as well
21:57:57 <Bjarni> the Windows solution is not to be able to tweak, meaning if you need to tweak, then you lost
21:58:21 <Bjarni> but indeed less stuff needs tweaking
21:58:46 <Eddi|zuHause> the thing i currently have to tweak every time i update is reverting a patch in kde's taskbar
21:59:25 <Eddi|zuHause> they changed the sorting from column-based to row-based, and that's completely silly
22:02:27 *** Markavian has joined #openttd
22:03:21 <Bjarni> I have a patch for something as well
22:03:46 <Bjarni> well I downloaded it from their patch upload thing
22:04:30 <Bjarni> seems like it's silly not to apply a bugfix, but then again it sometimes happens for OTTD because nobody has the time to read the diff
22:10:57 <Eddi|zuHause> keep it down pal, it's the middle of the night.
22:11:54 * Bjarni wonders if Sacro's neighbors will call the police because of all the sudden screams
22:12:03 <Bjarni> on the other hand they are used to it :P
22:12:27 <Sacro> Nah, not dealt with the police since friday
22:13:58 <Bjarni> as witness or suspect?
22:15:00 * Eddi|zuHause refrains from commenting that :p
22:34:36 *** Prof_Frink has joined #openttd
22:57:11 <Bjarni> Sacro: you ended up not telling about Friday :(
23:21:45 <SmatZ> congratulations, Master Bjarni :)
23:38:27 *** welshdragon has joined #openttd
continue to next day ⏵
