IRC logs for #openttd on OFTC at 2013-10-19
⏴ go to previous day
02:08:08 *** tokai|noir has joined #openttd
02:08:08 *** ChanServ sets mode: +v tokai|noir
03:31:23 *** Stimrol_ has joined #openttd
03:38:04 *** kristal has joined #openttd
04:56:17 *** Eddi|zuHause has joined #openttd
05:24:05 *** scshunt has joined #openttd
07:27:53 *** Pensacola has joined #openttd
07:56:06 *** andythenorth has joined #openttd
08:11:40 *** frosch123 has joined #openttd
08:24:00 *** LordAro has joined #openttd
08:27:08 *** andythenorth has joined #openttd
08:28:37 *** Alberth has joined #openttd
08:28:37 *** ChanServ sets mode: +o Alberth
08:30:45 <frosch123> hmm, what happened?
08:30:50 <frosch123> i was here before albert
08:34:39 <andythenorth> my fingers forget
08:34:46 <andythenorth> so when are we switching to git? o_O
08:36:18 <Alberth> as soon as they have useful patch queue support?
08:36:32 <Alberth> rebase stuff doesn't really appeal to me, so far
08:37:07 <andythenorth> I don't use rebase :P
08:37:31 <andythenorth> for me git has no advantage over hg, except that I currently have to use 3 different VCS on a daily / weekly basis :P
08:37:35 <andythenorth> 1 fewer would be nice
08:38:04 <LordAro> you can generally use git in place of all others, can you not?
08:38:13 <LordAro> certainly instead of svn
08:38:23 <andythenorth> LordAro: not when your production deployment environment depends on svn
08:38:30 <andythenorth> then you have to use svn
08:39:11 <LordAro> does git svn not work?
08:40:19 *** Progman has joined #openttd
08:40:30 <Eddi|zuHause> andythenorth: it maps the length to "use single part" or "use 3 magic parts" and defines which vehicle is the "master"
08:41:11 <andythenorth> wondering if I should copy your guards
08:41:24 <andythenorth> are they guarding against bad info in the tracking table input?
08:41:52 <andythenorth> ok, don't need that :)
08:42:04 <andythenorth> so you don't allow length > 16
08:42:20 <andythenorth> and obviously length < 3 is problematic :P
08:42:34 <andythenorth> maybe I should add guards for < 3 and > 10 (max length in this set)
08:42:41 <Eddi|zuHause> it's not "problematic" per se, just "not useful"
08:42:55 <andythenorth> it would be problematic for me
08:43:00 <andythenorth> I am enforcing 3 parts per vehicle
08:43:03 <andythenorth> no other option :P
08:43:28 <andythenorth> where is your useful dict of lengths?
08:43:30 <Eddi|zuHause> that sounds silly :)
08:46:46 *** zeknurn has joined #openttd
08:47:12 *** TomyLobo has joined #openttd
08:48:13 *** tst1488 has joined #openttd
08:48:27 *** andythen_ has joined #openttd
08:55:51 <andythenorth> invisible lead part makes depot stuff tricky
08:59:10 <andythenorth> well this is fun :P
09:00:48 <Eddi|zuHause> yes, that's why have a gui view template
09:12:59 *** valhallasw has joined #openttd
09:20:03 *** tokai|mdlx has joined #openttd
09:21:19 <zydeco> wouldn't be great if you could run commands from external files using the gamescript API or something
09:21:45 <LordAro> sounds potentially malicious, imo
09:22:38 <zydeco> I was thinking it'd be useful for custom editor commands
09:26:42 <peter1138> I think it's all sandboxed for a reason, heh
09:39:06 <andythenorth> trailing part weights are 0
09:39:46 *** montalvo has joined #openttd
09:45:19 *** gelignite has joined #openttd
09:47:32 <andythenorth> python get a property, with a default if failing?
09:49:41 <LordAro> anyone awake with windows development setup?
09:49:45 <andythenorth> getattr in this case :)
09:50:17 <Alberth> ooh, looking in the deep mystic parts of python o_o
09:50:28 <andythenorth> always seems a bit naughty
10:08:28 <Alberth> zydeco: are you Zydeco in the tt-forums? If so, did you consider implementing the new scenario format and use that?
10:19:12 *** ntoskrnl has joined #openttd
10:20:29 <zydeco> I am, but I'm not familiar with the new scenario format
10:24:53 <Alberth> the idea is to be able to make a scenario without having non-mutable newgrfs getting in there (they are supposed to be selectable after or during loading of the scenario. Also, the format allows 3rd party data to be expressed in an openttd readable format, much like your patch
10:25:28 <Alberth> this format could also include readme files, and a game script to be used alongside in the scenario
10:34:32 <zydeco> it would be easy to modify that into using latitude/longitude for towns
10:35:12 <Alberth> yeah, or add another format for expressing town data, or so
10:37:28 <Alberth> I don't know exactly what it proposes for towns, but requirements range from being specific down each house, to something very global like rough position and size. I can imagine you cannot express all those requirements in one format.
10:37:58 <zydeco> well, it could have some fields but not others
10:39:08 <Alberth> plenty of options to choose from
10:50:24 <zydeco> now I'm thinking about the road layer stuff
10:50:35 *** sla_ro|master has joined #openttd
10:51:04 *** HerzogDeXtEr has joined #openttd
10:52:04 <Alberth> that wiki-page is a global design without implementation, things can be changed
10:52:44 <Alberth> on the other hand, it might be better not to do that too long, in order to make real progress
10:55:33 <zydeco> is there any partial implementation?
10:55:50 <zydeco> I don't like the roads being 3x3 though
10:59:17 <Alberth> I have a patch queue from Terkhen with some general infra structure for having layers afaik
10:59:36 <Alberth> and I wrote a patch for writing a tar file
11:00:42 <zydeco> I think there should be about 17 road tile combinations for each road type
11:00:43 <Alberth> roads is indeed one of the problematic points, but so far a better solution for expressing one-way roads, and partial roads has not been found
11:01:10 <Alberth> an alternative could be to make all layers 3x3
11:01:44 <Alberth> the idea of using such layers is to support graphic editors that can edit images in layers
11:04:09 <zydeco> there could be one colour for north-south roads, another one for east-west, and another for junctions/curves which would be auto-generated according to the tiles on their sides
11:04:23 <zydeco> and other colours for one-way roads too
11:05:05 <zydeco> and if a pixel is a junction and only has a road on one edge, it would be a partial road
11:05:30 <zydeco> some things wouldn't be doable like this though
11:06:46 <Alberth> colour-coding will work for computers, but not for humans, I think, and indeed, being able to express everything you can do in openttd is important
11:06:52 <planetmaker> zydeco, yes. The problem is ... ^
11:07:12 <planetmaker> otherwise just different grayscales would work well
11:07:30 <planetmaker> but you cannot nicely draw that with your pixel editor of choice
11:08:17 <Alberth> ie imagine a person wanting to make a map in the editor
11:17:35 <DorpsGek> Commit by fonsinchen :: r25882 trunk/src/subsidy.cpp (2013-10-19 11:17:29 UTC)
11:17:35 <zydeco> maybe the usual cases could be done with 3 colours, n-s road, e-w road, and auto curve/junction
11:17:36 <DorpsGek> -Change [FS#5766]: Don't offer subsidies for auto-distributed cargo.
11:17:52 <zydeco> but it could also accept other colours for when auto junction doesn't work
11:21:52 <Alberth> would you be a happy person if you had to draw such roads in a graphic editor?
11:22:33 <zydeco> I don't know how detailed people usually make roads in scenarios
11:23:07 <Alberth> I don't know either, but at least you have roads in 2 directions, and junctions
11:23:27 <Alberth> which thus implies you need to switch colours constantly
11:23:49 <Alberth> and the graphics don't show you what you made
11:24:04 <Alberth> such things drove us to the current solution
11:24:06 <zydeco> actually, if it's just a single road, it could work with just one colour
11:25:35 <zydeco> the only time you can't do it automatically is if you have road tiles next to each other you don't want to be joined
11:26:15 <Alberth> and when you want an extension somewhere as hint where to start extending, for example
11:28:50 <Alberth> It'd be useful if you can express everything that openttd supports imho. You may be right that for many cases, a simple road layer may be sufficient
11:29:12 <Alberth> we could add that as another way to express roads
11:29:50 <Alberth> it'd need a bit of study what to do when you get both types of layers then, but that should be solvable
11:56:13 *** Pensacola has joined #openttd
11:57:17 *** montalvo has joined #openttd
12:01:11 *** andythenorth has joined #openttd
12:09:10 *** tokai|noir has joined #openttd
12:09:10 *** ChanServ sets mode: +v tokai|noir
12:11:47 *** tigeroo has joined #openttd
12:27:36 *** tokai|noir has joined #openttd
12:27:36 *** ChanServ sets mode: +v tokai|noir
12:52:29 *** retro|cz has joined #openttd
12:52:41 <andythenorth> now that I've built it
12:52:47 <andythenorth> I know what the design _should_ have been :P
12:53:26 <Alberth> that's quite normal :p
12:54:15 *** oskari89 has joined #openttd
13:17:12 <DorpsGek> Commit by fonsinchen :: r25883 /trunk/src (vehicle.cpp vehicle_base.h) (2013-10-19 13:17:06 UTC)
13:17:13 <DorpsGek> -Fix: Limit recursion and branching in RefreshNextHopsStats more aggressively.
14:16:35 * Alberth gets a bit tired of people trying to push ttdpatch features into openttd
14:16:58 <Alberth> in particular, for programmable signals :(
14:17:06 <andythenorth> my meh was because I didn't read my own code properly :P
14:19:54 * andythenorth doesn't understand
14:20:07 <andythenorth> why are we talking about signals, when newgrf effect vehicles still aren't done :P
14:20:23 <andythenorth> and objects can't be built by industries :P
14:20:51 <andythenorth> I have signals already
14:22:26 <Eddi|zuHause> concerning scenario roads: i'd settle for an option to just provide the road tiles and openttd figuring out the connections between on its own by detecting the neighbouring tiles. with some slight tweaking of parallel roads that should be sufficient for most people. it could have this 3x3 mode available as an option for people who need more details
14:24:45 <Alberth> (or openttd needing a simple export format :p )
14:36:10 *** DanMacK has joined #openttd
15:21:07 *** dihedral has joined #openttd
15:23:12 *** andythenorth has left #openttd
15:29:00 <DorpsGek> Commit by frosch :: r25884 trunk/src/window.cpp (2013-10-19 15:28:54 UTC)
15:29:01 <DorpsGek> -Fix: Resizing the window did not properly resize the viewport window, resulting in the link graph glitching.
15:38:34 *** skyem123 has joined #openttd
15:45:06 <frosch123> hearthstone tl open #1.... is that even a thing?
16:01:30 *** ChanServ sets mode: +v tokai
16:06:30 *** sla_ro|master has joined #openttd
16:21:05 *** Devroush has joined #openttd
16:47:07 *** tst1488 has joined #openttd
17:00:34 *** tst1488 has joined #openttd
17:09:19 *** DarkAceZ has joined #openttd
17:15:25 <DorpsGek> Commit by fonsinchen :: r25885 /trunk/src/linkgraph (4 files) (2013-10-19 17:15:19 UTC)
17:15:26 <DorpsGek> -Codechange: Keep paths sorted so that the ones with flow == 0 are in the back and don't have to be iterated over so often.
17:30:05 *** Ristovski has joined #openttd
17:45:15 <DorpsGek> Commit by translators :: r25886 trunk/src/lang/ukrainian.txt (2013-10-19 17:45:08 UTC)
17:45:16 <DorpsGek> -Update from WebTranslator v3.0:
17:45:17 <DorpsGek> ukrainian - 17 changes by Strategy
17:50:57 *** oskari892 has joined #openttd
18:29:01 <Eddi|zuHause> "In my experience, every problem is fun and logical once you get an understanding of it." <- i'd like to dispute that theory :p
18:30:40 <frosch123> nothing involving the axiom of choice is logical
18:30:45 <frosch123> that's my experience :p
18:38:22 *** andythenorth has joined #openttd
18:55:14 *** montalvo is now known as montalbeer
19:07:59 *** Supercheese has joined #openttd
19:42:02 *** lofejndif has joined #openttd
19:43:52 *** lofejndif has joined #openttd
19:48:15 <andythenorth> Alberth: against my judgement I'm using **kwargs a lot....I need to pass these on when calling super() in an __init__, but I need to modify them first
19:48:23 <andythenorth> kwargs['base_numeric_id'] = base_numeric_id <- seems incredibly wrong / ugly
19:50:00 <Alberth> just one value? otherwise you might want to consider dict.update
19:50:22 <andythenorth> might be more than one
19:50:39 <andythenorth> in principle it really shouldn't feel wrong
19:50:50 <andythenorth> it's just a dict
19:50:53 <andythenorth> but because **kwargs is magic, I don't trust it :P
19:50:54 <Eddi|zuHause> just add it at function call? f(blah=x, **kwargs=?
19:51:13 <andythenorth> yeah that works too
19:51:37 <Alberth> it's not really magic, it's just that you don't see what arguments you provide any more
19:51:49 <Eddi|zuHause> that should be the proper solution, as long as kwargs doesn't contain blah already
19:53:47 <Eddi|zuHause> then you probably have an architecture problem
19:55:49 <andythenorth> I do have an architecture problem
19:56:40 <andythenorth> I have base classes that know a bit too much
19:56:49 <Alberth> we tried having a class for the parameters one one already didn't we?
19:57:50 <Eddi|zuHause> at times like this i'm glad the CETS generator is not object-oriented :)
19:58:10 <Alberth> or just less parameterized :)
19:58:11 <andythenorth> all was well for the simple case
19:58:18 <andythenorth> now I need to stay out of OO-soup :P
19:58:30 <Eddi|zuHause> oh, i have functions of higher order instead :)
19:58:40 <andythenorth> the objects work really well for FISH, because ships are simple
19:58:50 <Alberth> you need a way to incrementally set the parameters instead of all at the same time
19:58:51 <andythenorth> and it works ok for FIRS, once you know the interface
19:59:17 <Eddi|zuHause> well, i do have classes for the parse tree of the graphics evaluation
19:59:56 <Eddi|zuHause> and a helper class or two
20:00:12 <andythenorth> I have a pretty nasty inheritance chain
20:00:35 <andythenorth> partly because trains can be wagons or engines, and the difference matters across multiple props
20:00:46 <andythenorth> and because I have to consider articulated parts
20:01:00 <andythenorth> and because I've layered in a load of extra crap about invisible articulated parts
20:01:12 <andythenorth> so there are now layers of nonsense
20:01:24 <Eddi|zuHause> see, for me those are just simple table entries
20:01:25 <andythenorth> dealing with 'must this propery be 0'
20:02:22 <andythenorth> Eddi|zuHause: so you just blat the table into props, and render whatever is there?
20:02:27 <andythenorth> with some guards?
20:03:14 <andythenorth> I found that a bit limiting with FISH
20:03:17 <Eddi|zuHause> i just noticed, i probably have no guards against "articulated part must be "spec"(ial)
20:04:32 <andythenorth> the object code I had a few weeks ago would have been fine, except the requirement to do > 8/8 vehicles
20:04:42 <andythenorth> which basically means fighting the game somewhat
20:07:26 <Eddi|zuHause> so why not just have a special (derived) class for 10lu vehicles, which handles the 3-part stuff?
20:07:54 <Eddi|zuHause> and keep 8lu and less the way it is?
20:08:10 <andythenorth> easier to just have everything as 3 parts
20:08:15 <andythenorth> in the long run :P
20:08:29 <andythenorth> the resulting code won't be too bad
20:08:37 <andythenorth> the problem is refactoring from one to the other
20:08:55 <Eddi|zuHause> there are some game mechanic problems
20:09:09 <Eddi|zuHause> like articulated vehicles can't be dualheaded
20:09:21 <andythenorth> we've removed those
20:09:26 <Eddi|zuHause> and can't be flipped around in the depot
20:09:43 <andythenorth> no flipping allowed then :)
20:11:18 <andythenorth> this might prove to be limiting in the set design in future
20:11:25 <andythenorth> only one way to find out...
20:11:50 <Eddi|zuHause> also, you can't use things like "count vehicle chain of same ID" and stuff
20:12:10 <andythenorth> and anything calculating offsets would be a nightmare
20:12:17 <andythenorth> nightmare / a bit of work
20:12:28 <andythenorth> e.g. I want props from neighbouring vehicles
20:12:54 <andythenorth> (not sprite offsets)
20:37:15 *** andythenorth has joined #openttd
20:50:12 *** Devroush367 has joined #openttd
20:57:33 * andythenorth found some more architecture suck that can be eliminated
21:21:14 *** HerzogDeXtEr1 has joined #openttd
21:44:53 <glx> but it's a good solution to prevent leaking of OEM disks
21:55:46 <__ln__> if it's a fake, someone has put a lot of effort into it
21:56:22 <Supercheese> my first reaction was, "that surely must be fake"
21:59:37 <__ln__> can't be fake, it's on the internet
22:20:31 *** Supercheese has joined #openttd
22:23:49 *** Supercheese has joined #openttd
23:01:16 *** treaki__ has joined #openttd
23:01:45 *** montalvo has joined #openttd
23:43:12 <Supercheese> "Facere ut auto-mutatio longitudinem hamaxostichi contineat ablatione curruum (primo primorum), si hamaxostichus longior fiat mutatione hamaxae"
23:50:59 *** roboboy has joined #openttd
23:59:15 *** treaki_ has joined #openttd
continue to next day ⏵
