IRC logs for #openttd on OFTC at 2010-06-06
⏴ go to previous day
00:22:30 *** zachanima has joined #openttd
00:37:57 <Eddi|zuHause> hm... is that a trick that my limited knowledge of slavic languages plays me or does "Belgrad" mean "Whitecastle"?
00:56:17 *** roboboy has joined #openttd
02:24:23 *** rhaeder1 has joined #openttd
04:01:31 *** deghosty has joined #openttd
04:19:35 *** De_Ghosty has joined #openttd
04:56:21 *** Eddi|zuHause has joined #openttd
05:20:09 *** Kurimus has joined #openttd
05:44:49 *** seirmubsa has joined #openttd
06:35:59 *** ^Spike^ has joined #openttd
06:49:48 *** einKarl has joined #openttd
07:19:47 *** devilsadvocate has quit IRC
07:28:22 *** devilsadvocate has joined #openttd
07:57:02 *** frosch123 has joined #openttd
08:25:49 <Yexo> TrueBrain / Rubidium: could either of you take a look at noai.openttd.org at lib-direction and lib-string? I've created those projects this morning but the svn repos don't work
08:26:05 <Yexo> when trying to checkout either of them I get "Could not open the requested SVN filesystem"
08:26:41 <Yexo> previously they were generated at *:18, has this been changed?
08:40:54 <frosch123> hmm, posting news is somewhat monologueish
09:02:41 *** devilsadvocate has quit IRC
09:14:43 <TrueBrain> Yexo: fixed and fixed
09:15:17 <TrueBrain> at least, I hope :p
09:18:45 *** fonsinchen has joined #openttd
09:34:06 *** woldemar has joined #openttd
09:37:58 *** KenjiE20 has joined #openttd
10:26:21 *** Progman has joined #openttd
10:33:52 <Rubidium> TrueBrain: should we celebrate the r10000 party's third anniversary?
10:35:01 <Rubidium> was it really on a wednesday?!?
10:35:23 <Rubidium> hmm, I guess because I went back to E'de at that day
10:39:21 *** Chillosophy has joined #openttd
10:55:22 *** Polygon has joined #openttd
11:15:26 *** [com]buster has joined #openttd
11:24:50 *** roboboy has joined #openttd
11:33:14 * andythenorth wonders if it's time to make the FIRS Aluminium Plant require electricity...
11:34:53 <andythenorth> think it will make gameplay too...brittle
11:36:12 <andythenorth> Eddi|zuHause, planetmaker any opinion? ^
11:36:35 *** |Jeroen| has joined #openttd
11:36:51 <planetmaker> require electricity = power plant nearby?
11:37:08 <andythenorth> yep, within n tiles
11:37:26 <andythenorth> 100% production if so, otherwise production 50%
11:38:01 <andythenorth> it would mean supplying the power plant with coal, so Aluminium would become very intensive on input cargos
11:38:21 <andythenorth> I can't think of a way to add a hydro plant to the game :P
11:38:52 <andythenorth> reality is most Aluminium Mills are near hydro, geo-thermal or nuclear generators
11:39:25 <planetmaker> hydroplant... and industry with water and land tiles
11:39:51 <andythenorth> needs to be on a river....wallyweb faked one once, but rivers are not exactly in common use
11:40:05 <andythenorth> (wallyweb faked a hydro plant that is)
11:40:08 <planetmaker> well, don't rely on it. But would be nice :-)
11:40:22 <planetmaker> it would only accept ENSP
11:41:10 <andythenorth> rivers in world generator any time soon? Probably not....?
11:41:18 <planetmaker> if there's space... please add one :-)
11:41:29 <planetmaker> maybe even if it requires a river in the middle. I'd love that!
11:41:39 <planetmaker> It'd give scenario makers incentive ;-)
11:41:54 <andythenorth> I'd do it if the world generator provided rivers
11:42:12 <planetmaker> it doesn't yet. But it's easily possible in the SE.
11:42:19 <andythenorth> I know, but who bothers :P
11:43:08 <andythenorth> hydro plant would need quite some thought
11:43:24 <planetmaker> it'd be IMHO a nice easter egg :-)
11:43:29 <planetmaker> for those who care :-)
11:43:39 <andythenorth> controlling placement would be a nightmare
11:43:52 <andythenorth> it would need a very precise difference in height levels
11:43:55 <planetmaker> not really. Just require one, two layouts, that's it.
11:44:24 <planetmaker> or maybe four layouts. Each direction one
11:44:27 <andythenorth> if it was just 1 or so tiles across a river that would work
11:44:45 <planetmaker> that's what I thought with one, two adjacent tile left/right of the river
11:44:56 <andythenorth> work for another day though
11:45:22 <andythenorth> so much else to do on FIRS :)
11:53:50 <andythenorth> I need to do something about empty tiles. My layouts look better with some tiles mostly empty. But Simon Foster didn't have empty industry tiles.
11:54:16 *** ChanServ sets mode: +v tokai
11:56:02 <planetmaker> add cargo there depending upon production
11:56:36 <planetmaker> possibly also upon how much is shipped
11:56:48 <Ammler> he, you you need them looking like Foster industries?
11:57:47 <andythenorth> was metropolitan airport in the original game?
11:58:35 <andythenorth> city airport has empty tiles
11:58:40 <andythenorth> so there is a precedent :P
12:00:07 <andythenorth> it would be nice if industries were fenced by default, but the fences were removed if a station tile is adjacent
12:00:18 <andythenorth> I think that's possible, but I don't know if I can be bothered to work it out :o
12:06:57 <planetmaker> I guess it's possible. You'd need to check adjacent tile type
12:10:01 <planetmaker> Rubidium: what's your view on introducing 32bpp replacements basically only via newgrf?
12:10:10 <planetmaker> where there's always a 8bpp fall-back?
12:10:21 *** ajmiles has joined #openttd
12:10:46 <planetmaker> the more I think about that approach the more I like it
12:11:08 <planetmaker> As it means that no other changes are needed than extending the newgrf specs
12:29:30 *** fonsinchen has joined #openttd
13:08:14 *** frosch123 has joined #openttd
13:11:02 *** ChanServ sets mode: +v tokai
13:35:08 *** rhaeder has joined #openttd
13:40:53 <ccfreak2k> andythenorth, maybe investigating the fence code for railroad tracks is a good start.
13:45:11 <OwenS> planetmaker: I remember one of the Patch devs discussing 32-bpp in GRF a while back
13:52:24 <frosch123> including 32bpp directly into the grf is very stupid, as it makes the md5sum depend on 32bpp included
13:52:37 <frosch123> but, well, rb already wrote everything on the forum
13:54:09 *** asnoehu has joined #openttd
13:54:16 *** ChanServ sets mode: +v glx_
13:54:52 *** asnoehu is now known as tycoondemon
13:55:47 <OwenS> frosch123: Would it not be sane for NewGRFs? The currrent separate system is rather unfriendly
13:56:21 <Eddi|zuHause> andythenorth: if grfcodec errors out with "Could not parse unquoted escape sequence. While reading sprite:1204" is that my fault, my ancient grfcodec's fault or your fault? (while compiling firs)
13:56:35 <andythenorth> Eddi|zuHause: let me see
13:56:35 <frosch123> OwenS: you can put the grf and the png in one tar, so it is not unfriendly at all
13:57:01 <frosch123> there is absolutely no difference for the user between downloading one grf or one tar
13:57:24 <frosch123> but there is a big technical advantage to not use grf for 32bpp
13:57:34 <Rubidium> OwenS: 32bpp seems to be about 50 to 100 times larger than 8bpp
13:57:39 <OwenS> frosch123: OK, so what is the technical downside of packing everything into the GRF? It changing the md5sum is a non-issue as I would expect that GRFs would come natively with 32bpp...
13:57:40 <andythenorth> Eddi|zuHause: I don't know....can you paste sprite 1204 (from compiled firs.nfo)?
13:57:56 <Rubidium> OwenS: would you like a NewGRF being that much larger if you only need/like 8bpp
13:58:18 <OwenS> Rubidium: GRF author's decision. Besides, if the author is shipping a tar, same issue. And its not like it takes time to download...
13:58:38 <frosch123> OwenS: can you name any advantage for putting them in the grf? i see only disadvantages
13:58:54 <OwenS> frosch123: Lets see... Less fragile. The current system breaks if any sprites get renumbered
13:59:15 <frosch123> OwenS: that is no reason
13:59:16 <Rubidium> OwenS: but I proposed separating the 8bpp from the 32bpp in bananas, so if you need only 8bpp you need to download only the 8bpp part, not the 32bpp stuff
13:59:25 <frosch123> that is only a matter of the tool which creates the tar
13:59:37 <andythenorth> Eddi|zuHause: what rev FIRS do you have? That looks like experimental code which should be removed / commented out?
14:00:09 <OwenS> Rubidium: The average user doesn't understand 32bpp. "Why do I have to download *two* files to make the graphics fit together?"
14:00:28 <Eddi|zuHause> what's the hg equivalent to "svn info"?
14:00:31 <frosch123> OwenS: that is no reason either, you can include the grf into the tar
14:00:48 <frosch123> you could provide a tar without the 32bpp sprites, and one with
14:01:06 <frosch123> bananas already deliveres every grf in a tar
14:01:15 <OwenS> frosch123: OK, and now the user has to figure out which one to download
14:01:36 <OwenS> How many people really care about the extra few kilobytes that 32bpp graphics add?
14:01:37 <frosch123> great, the user also has to figure out whether to download the win32 or win64 build
14:01:38 <Eddi|zuHause> andythenorth: changeset: 868:33e592546dfe date: Sun May 30 18:13:26 2010 +0100
14:01:49 <Rubidium> OwenS: they can be represented as 1 "file" inside openttd
14:02:01 <frosch123> OwenS: the user just has to decide whether he wants to download the 1mb 8bpp graphics, or the 50mb 32bpp graphics
14:02:36 <OwenS> Rubidium: And on bannanas?
14:02:44 <OwenS> How does it decide which one too download?
14:03:11 <Rubidium> OwenS: if 32bpp, then download the 32bpp "extra" pack + the 8bpp
14:03:32 <Rubidium> upgrade selects all 32bpp graphics of already existing 8bpp graphics if 32bpp is chosen
14:03:34 <OwenS> Rubidium: OK. And then the user switches from 8bpp to 32bpp. How do you handle this?
14:04:13 <andythenorth> Eddi|zuHause: do you have a FIRS save game? I am going to fix that and commit - but FIRS is very *not* save game compatible at the moment :o
14:04:24 <Eddi|zuHause> no, i have not ;)
14:04:46 <planetmaker> I guess a good way would be a checkbox in the download window: [x] download 32bpp version
14:05:11 <OwenS> planetmaker: And now you need to teach users what 32bpp means
14:05:22 <frosch123> OwenS: you can imagine 3 types of files, 8bpp only, 32bpp+8bpp, and 32bpp-upgrade for already downloaded 8bpp
14:05:23 <planetmaker> [x] download true colour
14:05:28 <frosch123> all of them are tars, and single files
14:05:52 <planetmaker> frosch123, that sound unnecessary. Rather two is sufficient
14:05:53 <frosch123> though i doubt the 32bpp-upgrade is worth it, the 8bpp part likely does not matter
14:06:03 <andythenorth> Eddi|zuHause: try the newest FIRS - I've just pushed
14:06:10 <andythenorth> there are 3 known compile errors
14:06:52 <Eddi|zuHause> *mental note* "git fetch" won't work on a hg working copy :p
14:08:11 <Eddi|zuHause> andythenorth: now there are plenty of renum-errors
14:08:31 <Eddi|zuHause> but it did create a firs.grf
14:08:53 <andythenorth> I get two renum errors, both non-critical warnings, and also some white pixels
14:09:31 <andythenorth> my renum is old, I've tried to update it, but I can't figure out how to put it in the path for make :P
14:10:11 <Eddi|zuHause> andythenorth: yesterday it did have only the 2 warnings
14:10:17 <andythenorth> that's rather a lot. suspect I forgot to commit a file
14:10:21 <andythenorth> yup I can guess which one :P
14:10:24 <OwenS> I still think that its overcomplicating things
14:11:16 <andythenorth> Eddi|zuHause: I've pushed a fix for the missing file :0
14:11:45 <Rubidium> OwenS: agreed, just forget the whole 32bpp thing
14:12:12 <Eddi|zuHause> andythenorth: yup, better now
14:12:17 <OwenS> Rubidium: No. Just have one architve. Whether thats tar, or intergrated grf, doesn't matter :p
14:12:46 <Jupix> Rubidium: can I put that in my sig?
14:12:57 <andythenorth> Eddi|zuHause: what do you think of the revised Aluminium Plant?
14:13:28 <Eddi|zuHause> hm, why does renum return errorlevel 3 when warnings occured, but errorlevel 4 (higher=less severe) when errors occured?
14:14:37 <Rubidium> Jupix: feel free if you think that helps your cause
14:15:02 <__ln__> btw, it's spelled 'occurred'
14:15:24 <Eddi|zuHause> i have a feeling the 32bpp project is heading in the wrong general direction currently
14:15:36 <Eddi|zuHause> __ln__: whatever ;)
14:15:45 <Rubidium> Eddi|zuHause: so do I
14:15:50 <__ln__> Eddi|zuHause: i only figured that out a month ago myself :)
14:16:04 * andythenorth doesn't understand 32bpp
14:16:07 <frosch123> OwenS: fine, so give the tar a differen filextension
14:16:12 <andythenorth> what is it exactly?
14:16:13 <Eddi|zuHause> __ln__: any version i tried in the past did look kind of wrong...
14:16:20 <Jupix> feel free to post the "right" direction in the forums, that's why they're there
14:17:30 <Jupix> (in the org thread preferably)
14:18:51 <Jupix> also, it might be good if you put into words where you *think* it's heading, since it's most likely mistaken since you think it's a bad thing
14:19:04 <Eddi|zuHause> Jupix: there's a fundamental difference between noticing something is wrong, and determining what is right instead :p
14:19:55 * andythenorth blew up the game
14:20:13 <Jupix> Eddi|zuHause: I know, but I can't do much if you just say something's "wrong"
14:20:33 <Eddi|zuHause> i'm not in the mood to discuss that right now...
14:20:34 <Jupix> whereas if you pitch an idea and it's a good one, I can try to steer things into that direction
14:20:48 <Eddi|zuHause> maybe some day...
14:21:06 <frosch123> andythenorth: basically there are two parties about 32bpp: those who want it, do not know how it works, and blame ottd to add support. and those who know how it works, know that ottd supports it for 3 years, and are not interested in it
14:21:14 <Eddi|zuHause> i could pull a MB and say "i have said that before" :p
14:21:49 * andythenorth goes back to compiling grfs that crash the game :P
14:21:56 <andythenorth> frosch123: thanks btw
14:21:59 <frosch123> Jupix: just read ammlers post frmo three days ago
14:22:38 <frosch123> the "rest" is just packaging
14:23:14 <OwenS> frosch123: Theres a thrid party: Those of us who want it, know OpenTTD supports it, and wishes the graphics were all combined together in some trunk-friendly package (Maybe they are now?)
14:24:18 * andythenorth finds another case in FIRS which could use 'field tiles' :)
14:24:19 <Jupix> frosch123: you're telling *me* to read the 32 bit forums?
14:24:30 <Rubidium> Jupix: bounding boxes are a bitch and designed for the current graphics. With correctly scaled (3-5? times as) long wagons/engines you'll end up in a hell of sprite ordering glitches because of the "crude" ordering
14:25:07 <Rubidium> which would mean totally rewriting the sprite ordering, possibly removing the hacks
14:25:18 <frosch123> oh, long vehicles again :p even more important there is fundamental design in ottd which requires a vehicle to be only on one tile at everytime
14:25:33 <Jupix> we're not pushing for that feature at this time
14:26:00 <frosch123> Rubidium: actually you have to trash sprite ordering and add z buffers instead
14:26:01 <Rubidium> which would mean bridges need to go higher and that implies bridge heads getting two tiles long
14:26:44 <Rubidium> and then "the slopes" are too steep, so they need to become less steep this the bridge head becomes 4 tiles long
14:27:08 * Jupix is not listening and doesn't really care either
14:27:14 <Jupix> it's Ben's feature request
14:27:48 *** Chruker has joined #openttd
14:27:48 <Jupix> what I *do* care about is the packaging, as you so elegantly put it
14:28:08 <Jupix> as that makes all the difference in how the "32bpp thing" is perceived these days
14:28:49 <Jupix> as long as it's just a hack that *may* work after hours of newbie-hacking of the client, it has no chance, and I don't like that
14:29:48 <frosch123> Jupix: again, there are absolutely no changes required to ottd at the moment.
14:30:25 <Jupix> yes, it boots and displays 32 bits without changes, but it sucks
14:30:32 <frosch123> you want a single file package which adds 32bpp sprites to the game in a toggleable form, right?
14:30:32 <Jupix> making changes would make it better for the player
14:30:59 <frosch123> independent of other grfs and their spritenumbering
14:31:51 <Rubidium> and something that works with upcoming (not yet released) grfs as well?
14:32:25 <Jupix> frosch123: I can look it up if you really care. :D
14:32:46 <frosch123> Jupix: the link you gave me is about technical format details, not what you want to do
14:32:53 <Jupix> though a solution would be more useful than a "xxx's wrong" refuttal :D
14:33:40 <frosch123> so i put it like that: you want a 32bpp baseset selectable from the game options?
14:34:34 <Jupix> and downloadable next to ogfx in the content service, that's very important, and I thought it'd make sense if it was the same format used for 8 bit gfx
14:35:06 <frosch123> ok, content service won't work for now, and considering the bandwidth i do not favor it either
14:35:13 <Jupix> fewer sprite delivery methods to support and teach new artists
14:35:44 <frosch123> i do not understand that
14:36:33 <Jupix> well, currently, if you want to distribute 8 bit gfx, you need to learn how to make them into .grfs... correct?
14:36:57 <frosch123> i doubt you can invent a format which does not require learning
14:37:05 <Jupix> just answer the question
14:37:28 * Rubidium wonders what is wrong about teaching NML about 32bpp graphics
14:37:43 <frosch123> Rubidium: nothing, just noone in interested yet to add it
14:38:06 <Jupix> and currently, if you want to distribute 32 bit gfx, you need to learn how tars work. if 32 bit gfx went into grfs, you'd only need to learn how *they* work
14:38:48 <Rubidium> Jupix: again, my suggestion should solve that
14:39:01 <Jupix> so if GRFs were the only sprite delivery method, it would make the ecosystem simpler for a newbie who wants to learn how to do things
14:39:04 <frosch123> "currently yes". but that is only a matter of tools. nml has the potential to replace nforenum, grfcodec and tar
14:39:13 <frosch123> it already combines the first two
14:39:52 <Rubidium> Jupix: consider that grfcodec and nforenum could be considered abandoned
14:40:01 <Jupix> I don't really care how it's solved. what I'm trying to say is that it's currently suboptimal and whatever the solution, would be an improvement, as long as it addresses to concerns that I've written up in the forums
14:40:25 <frosch123> fine, jupix, then think of nml as your solution.
14:42:14 <Ammler> basically, currently only basesets (without the extra) supports 32bpp replacement easy
14:43:24 <Ammler> the extra grf and newgrfs conflict with the static sprite number
14:44:00 <frosch123> Ammler: you are thinking in the way of an add-on. the method to release a 32bpp-addon which should work with any 8bpp replacement set is broken in itself
14:44:08 <frosch123> the 32bpp-one needs to be a baseset itself
14:44:33 <planetmaker> Jupix, you seem to have gotten me completely wrong
14:44:38 <Ammler> yes, with it's own extra grf, which they have
14:44:57 <Ammler> but still, you can't change sprite number that easy.
14:45:00 <frosch123> it should also have its own basic grfs
14:45:07 <Ammler> specially if you like to use 32bpp in newgrfs
14:45:16 <frosch123> even if they only contain pure black sprites with white text "activate 8bpp!"
14:45:20 <Jupix> planetmaker: please don't spin the forum discussion into an IRC discussion, that'll leave everyone else confused :)
14:45:34 <planetmaker> Jupix, a base set needs to be per definition at least 8bpp.
14:46:11 *** fonsinchen has joined #openttd
14:46:11 <planetmaker> since 8bpp is _base_, the minimum requirement for OpenTTD to do anything
14:46:20 <planetmaker> 32bpp may be included on top.
14:46:25 <Ammler> maybe nml could beside the 8bpp sprites also have a path to the 32bpp graphics, with offsets
14:46:26 <planetmaker> You may that then call 32bpp base set
14:47:05 <frosch123> Ammler: it could also encode directly into a tar including readme and license and such
14:47:10 <frosch123> just someone has to do it :p
14:47:53 <planetmaker> frosch123, would it make sense to make OpenGFX 8bpp release and OpenGFX 8+32bpp release?
14:48:12 <planetmaker> should be moderately easy to sustain
14:48:17 <Jupix> planetmaker: I just don't get the "why" of that
14:48:26 <planetmaker> Jupix, _base_ set
14:48:42 <Jupix> yeah, but why can't the base be in 32 bits?
14:48:45 <planetmaker> if you only have 32bpp any person having a 8bpp display would not be able to use the base set
14:48:54 <planetmaker> and a base set per definition runs on any platform
14:49:06 <Ammler> hmm, maybe geekto should simply change the 32bpp-extra to 32bpp-baseset
14:49:09 <planetmaker> so any 32bpp per definition has to ship 8bpp, too
14:49:37 <planetmaker> you'd break OpenTTD completely, if you don't have a 8bpp alternative to 32bpp
14:49:40 <Jupix> planetmaker: ok, so suppose someone has an 8 bit display. why is he downloading the 32 bit base set instead of the 8 bit options?
14:50:08 <planetmaker> Jupix, currently everything "just works".
14:50:14 <planetmaker> Changing that is IMHO not a good thing
14:50:19 <frosch123> it is not worth to discuss 32bpp only stuff, 8bpp can be included at zero cost
14:50:23 <Jupix> everything except 32 bit gfx
14:50:31 <frosch123> even if it is only black on white
14:51:10 <planetmaker> Jupix, I don't get why you want to throw away compatibility only for the vanity of "32bpp only set"
14:51:21 <Ammler> does nml support Action5 already?
14:52:10 <Jupix> planetmaker: what is it exactly that would remove compatibility? last I checked, ottd ships with NO base set
14:52:22 <Jupix> you've got a choice of 3 instead of 2
14:52:29 <Jupix> that's the only difference
14:52:35 <planetmaker> Jupix, yes. And then it breaks, if one switches blitter. BIG difference
14:53:02 <Jupix> why would you enable the 32 bit blitter if you have a 8 bit display, and why'd you program it to break?
14:53:42 <planetmaker> why wouldn't I want the possibility to chose either or - and why would I get an unusable OpenTTD, if I change to 8bpp when I used 32bpp before?
14:53:56 <planetmaker> meh... I guess this discussion is not worthwhile
14:55:07 <Jupix> how would the switch from 32 to 8 be any different from the one from 8 to 32 :|
14:55:16 <planetmaker> at least I cannot break OpenTTD easily right now by changing the config
14:55:27 <Jupix> I just don't see the breakage
14:55:29 <planetmaker> Jupix, both, blitter and base set are different settings
14:55:38 <planetmaker> I play 32bpp with your 32bpp only-base set.
14:55:56 <planetmaker> Then I change the blitter to 8bpp - and voila, OpenTTD is unusable if I didn't manually also switch the base set
14:56:04 <planetmaker> something I currently do comfortably ingame
14:56:24 <Jupix> make the feature, you know, not stupid?
14:56:41 <Jupix> it doesn't have to be that robust
14:56:55 <planetmaker> if it doesn't need to be robust it doesn't have to be
14:57:24 <Jupix> besides, zephyris suggested a solution that would solve that
14:57:43 <Jupix> in essence, you'd generate 8 bit sprites on the fly
14:58:10 <frosch123> maybe we should link agains imagemagick and also scale the graphics on the fly
14:58:47 <frosch123> we could also link against some pythonlib and read nml directly
14:59:24 <frosch123> we could also link some artificial intelligence which draws the graphics in the first place, or better, code ottd inself
14:59:59 <frosch123> Jupix: in other words, ottd does not need to include stuff, which are not needed by the average player, but can be done with an external toolo
15:01:04 <Jupix> do you consider 32bpp-ez "not needed by the average player"?
15:01:48 <frosch123> no, but i consider generting 8bpp on the fly in ottd sub omni canone stupid if you can do the same with an external tool and add it to the baseset
15:02:19 <frosch123> oh, i missed the "-ez" part
15:02:34 <frosch123> i am not interested in "-ez" at all
15:03:11 <frosch123> everything with > 2x zoom is unplayable
15:03:34 <Jupix> out of curiosity, have you played on a 30" tft screen?
15:04:03 <Ammler> frosch123: I sometimes use the zoom function of my WM
15:04:05 <Jupix> because in my experience anything *out* of -EZ is unplayable
15:04:43 <Jupix> anyway, what I also wanted to know is, do you also think that ottd should contain those features that you want, and those only?
15:04:52 <Jupix> because that's how you come across to me
15:05:13 <frosch123> Jupix: i will only spent work on stuff which am interested in
15:05:29 <Jupix> then don't work on it, instead of slamming it on IRC
15:05:32 <Ammler> Jupix: that is how opensouce works mostly
15:06:59 * andythenorth draws some pixels
15:07:01 *** egladil has joined #openttd
15:09:24 <frosch123> Jupix: and i will also *vote* against stuff which breaks stuff i am intested in, or which is done *technically* wrong in my opinion. if that leads to unresolvable conflicts, the minority has to split off
15:10:36 *** [com]buster has joined #openttd
15:10:37 <frosch123> and usually i comments on *technically* wrong stuff as early as i notice
15:10:50 <frosch123> if that feedback is not welcome, i do not care
15:11:09 <Jupix> saying "do it my way or GTFO" isn't going to convince me to change my mind
15:12:20 <frosch123> also fine, but don't complain about that
15:12:36 <Jupix> what you need to understand is that I don't care about the technical stuff, blitters, GRFs, spriteloading or whatever, but I do care when people close to me say they'd like to try ottd-32bit but it's too confusing
15:12:52 <Jupix> I'm trying to solve that, not push a technical solution
15:12:59 *** NukeBuster has joined #openttd
15:13:13 *** mucht_home has joined #openttd
15:13:15 <frosch123> as i said before. there are two parties. those who are interested in it, and do not know how it works. and those who know how it works, but are not interested
15:13:22 <frosch123> i have no idea, how to solve that
15:14:11 <Jupix> I think there are a lot of people who have said before that if you generalise, you're always wrong :)
15:14:57 <Mitch_1_2> Is it possible to resize a station?
15:15:31 <frosch123> Mitch_1_2: you can build additional tiles directly adjacent, resp. while holding ctrl also non-adjacent
15:15:46 <frosch123> and you can remove single tiles by selecting the "bulldozer"
15:22:08 * Rubidium wonders how well a "simple" downscale from over 16 million colours to less than 200 colours actually works
15:23:30 <frosch123> that depends on how colourful the image is
15:23:39 <frosch123> a colourramp will look awful
15:24:07 <frosch123> for a photo you will hardly notice if it applied to all images nearby
15:24:55 <frosch123> alpha channel is likely also very troublesome
15:26:57 <frosch123> otoh, artists would notice it in any case, just like musicians can hear whether their audio plugs are made of gold or not
15:27:27 <OwenS> frosch123: Blind trials have demonstrated they can't :p
15:27:50 <Rubidium> blind trials on 32bpp vs 8bpp graphics? :)
15:29:16 <Mitch_1_2> Hmm. Stupid station not accepting passengers.
15:29:21 <frosch123> double-blind-experiments are said to be very trustworhty
15:30:26 <OwenS> Rubidium: On gold vs nickel connectors :p
15:30:35 <andythenorth> Eddi|zuHause: any opinion on new FIRS aluminium plant graphics?
15:30:49 <Eddi|zuHause> haven't checked yet...
15:31:12 <OwenS> On the other hand, they can tell the difference between audio *cables*. And the best are the solid core copper used for mains wiring :p
15:31:58 *** Plimmer has joined #openttd
15:32:38 <Mitch_1_2> frosch123: Any idea why a train station wouldn't accept passengers?
15:34:11 <Plimmer> Hi, me and 2 friends are playind Openttd with alot of ECS vectors enabled on a reasonably hard setting. Our problem is that alot of the industries close down along time before we have the resources to build a decent network to actually transport alot of theese industries. Is there some setting that will allow me to extend the closure of theese industries?
15:34:57 <andythenorth> industry closure strikes again :P
15:35:31 <Plimmer> Heh, yeah. Kinda sucks to have to fund all you want to drive with. :)
15:42:14 <frosch123> Mitch_1_2: use the land are information tool on the very right of the menubar to discover which tiles accept what cargo
15:42:34 <Mitch_1_2> frosch123: Thanks. You're full of answers. :)
15:42:46 * Mitch_1_2 tries to find out himself. Honest.
15:50:27 <Eddi|zuHause> Plimmer: no, that is currently an unsolved problem
15:50:39 *** Chris_Booth has joined #openttd
15:51:15 <andythenorth> I think there might be an ECS parameter to disable closure?
15:51:34 <Eddi|zuHause> andythenorth: only closure of serviced industries, not of unserviced industries
15:52:00 <Eddi|zuHause> oh, mine closure in all cases separately, which might help
15:52:43 <Eddi|zuHause> Plimmer: i generally set the "general behaviour" parameter to "12", not sure if that helps you...
16:02:11 *** ChanServ sets mode: +v tokai
16:02:14 *** Eddi|zuHause2 has joined #openttd
16:14:25 <asilv> grfcrawler has "Can't connect to TT-Forums Database" error again, who should I complain to?
16:15:45 <SpComb> asilv: orudge and eis-os
16:15:52 <asilv> do they actually ever talk ttd related stuff at #tycoon
16:16:21 <frosch123> last time i got that error it worked nevertheless
16:16:43 <SpComb> it uses tt-forums usernames for logins
16:17:03 <frosch123> oh, ok, i did not had to login
16:18:05 <orudge> should be fixed again now
16:18:21 <asilv> works now thanks, orudge!
16:19:28 *** Eddi|zuHause2 is now known as Eddi|zuHause
16:26:52 * frosch123 pondered buying a ottd shirt for the party, but they are just too ugly :s
16:28:54 *** DorpsGek changes topic to "1.0.1, 1.0.2-RC1"
16:30:57 *** glx changes topic to "1.0.1 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | UTF-8 please | No Unauthorised Bots | Continental breakfast only | Don't ask to ask, just ask"
16:31:13 *** DorpsGek changes topic to "1.0.1, 1.0.2-RC1 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | UTF-8 please | No Unauthorised Bots | Continental breakfast only | Don't ask to ask, just ask"
16:31:52 <glx> I forgot an arg in the command ;)
16:32:25 <Sacro> continental breakfast sounds nice
17:27:24 *** woldemar has joined #openttd
17:45:32 <CIA-2> OpenTTD: translators * r19940 /trunk/src/lang/unfinished/ (maltese.txt urdu.txt):
17:45:32 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:32 <CIA-2> OpenTTD: maltese - 2 changes by kelinu
17:45:32 <CIA-2> OpenTTD: urdu - 1 changes by zohair
18:19:36 *** devilsadvocate has joined #openttd
18:39:41 *** Wintersoldier has joined #openttd
18:40:04 *** Wintersoldier has left #openttd
18:59:40 <__ln__> how much money do i save by purchasing train tickets e.g. one day in advance? (if any)
19:03:12 <frosch123> in germany? iirc you can save 25% if you decide three days in advance for a specific train (you then should not miss)
19:05:27 <__ln__> does that apply to RE and IR and such too?
19:05:57 <frosch123> no, that is ice only (maybe ic)
19:06:34 <frosch123> for re there are other tickets for a weekend or a state
19:06:47 <frosch123> and i guess IR does not exist anymore
19:07:01 <__ln__> yeah, i've even used ländertickets a couple of times.
19:08:53 <frosch123> oh, maybe you can even save 50% on ice on weekends
19:09:06 <frosch123> (but still for a specific train only)
19:09:41 <Rubidium> isn't/wasn't there some really cheap ticket which only lets you go in regional trains?
19:10:03 <planetmaker> yes. The "schöne Wochenende"-tickets
19:10:15 <planetmaker> but they're meanwhile only valide one day, not both :-(
19:10:23 <planetmaker> and cost like 25 or 30€
19:10:32 <planetmaker> Not worthwhile for __ln__ from Hanover to BS
19:10:43 <planetmaker> that's only ~10€ one-way
19:11:01 <Rubidium> they seem to be 37 euros
19:11:11 <planetmaker> even more expensive
19:11:21 <planetmaker> and then you share the train with a lot of drunken scum
19:11:38 <__ln__> yeah, and within the borders of niedersachsen-ticket anyway (~20€)
19:12:43 <Rubidium> oh, that ticket is for up to 5 persons
19:13:19 <planetmaker> that's the pro, if you go in a group
19:13:21 <__ln__> for 5 persons it's ridiculously cheap
19:14:32 <__ln__> i'm more considering what to do after BS... go more or less directly to berlin, or explore some eastern city first.
19:21:39 <__ln__> (what a conversation killer)
19:23:54 <frosch123> when do you fly back?
19:24:32 <frosch123> oh, so two days for other stuff
19:25:56 <planetmaker> __ln__: Berlin is in the East ;-)
19:26:13 <planetmaker> __ln__: when do you arrive?
19:26:27 <Rubidium> planetmaker: it's all west of Finland
19:26:49 <planetmaker> Rubidium: also East. Just more distant ;-)
19:27:11 <__ln__> friday 18th to hannover (unless a volcano blows up or something)
19:27:25 <planetmaker> you come over already on 18th?
19:27:38 <planetmaker> you're free to do so, if you like
19:28:12 <__ln__> no, i booked a cheap ho(s)tel thing in hannover for one night.
19:29:20 <__ln__> and a cheap hotel thing in BS for the next.. (sleeping bag accommodation would be ok as such, but i ain't carrying one halfway through europe :) )
19:29:45 <planetmaker> whoot, you booked one here, too?
19:31:07 <planetmaker> ok, I don't know it. The location looks quite ok, though
19:31:24 <planetmaker> about where one of the bigger public viewing sites is located :-P
19:31:50 <planetmaker> *somewhere* in the Bürgerpark
19:35:02 <planetmaker> __ln__: what kind of touristic activities are you into?
19:36:02 <__ln__> walking around and photographing interesting things... :)
19:36:32 <planetmaker> if you feel like I can give on Sunday a free tour through town
19:37:06 <planetmaker> what's 'interesting' in your eyes, though?
19:37:39 <planetmaker> like history? Like architecture? arts?
19:38:27 <__ln__> buildings, trams, nice views, ...
19:39:59 <planetmaker> hm... So should I look whether there's on Sunday a ride through town in one of the historic trams ;-)
20:21:41 *** Brianetta has joined #openttd
20:35:13 *** HerzogDeXtEr1 has joined #openttd
21:06:18 *** Polygon has joined #openttd
21:14:24 *** fonsinchen has joined #openttd
21:30:38 *** theholyduck has joined #openttd
21:55:14 <Eddi|zuHause> "Due to numerous complaints about the domain name" <- who would do that? :p
22:03:34 <Eddi|zuHause> no, that's not the website in question ;)
22:15:54 *** wollollo has joined #openttd
22:17:47 *** theholyduck has joined #openttd
22:20:55 *** wollollo has joined #openttd
22:22:52 <Rubidium> Eddi|zuHause: google doesn't know any website with that
22:28:13 <Rubidium> Wizzleby: the 320797 sounds like a broken grfcodec
22:29:43 <Rubidium> I seem to remember the same problem occuring under SLES 12 or something
22:34:27 *** ChanServ sets mode: +v tokai
22:36:28 *** devilsadvocate has quit IRC
22:36:34 *** devilsadvocate has joined #openttd
22:40:59 *** PeterT is now known as PeterT-ghost
22:41:21 *** PeterT-ghost is now known as PeterT
22:55:05 <Wizzleby> Rubidium: the thing that baffles me about it at the moment, is that so far, some have been unable to replicate it
22:56:22 <PeterT> the "graph" at the new site at github is nice, Eddi|zuHause
22:57:53 <Wizzleby> Rubidium: well, both of us who have encountered it were using gcc-4.5.0, I'm preparing to test with 4.4.3
22:58:08 <Rubidium> Wizzleby: do you use glibc 2.11?
22:58:37 <PeterT> sorry, Eddi|zuHause, just cause you mentioned the link
22:58:42 <PeterT> I was looking at my buffer
23:00:50 <Rubidium> in any case, the test is correct as it caught that something is broken
23:04:43 <Rubidium> okay, seems to be gcc 4.5
23:06:03 <Rubidium> and gcc trunk of yesterday-ish has the problem too
23:06:23 <Wizzleby> I'm unsurprised, when I first made a grfcodec ebuild, it was lacking a patch (now applied upstream) to work with gcc-4.4
23:09:06 <Rubidium> compiling with -O0 "solves" the problem
23:09:42 <Wizzleby> Ahh.. I was wondering if the gcc-4.5.0 optimization scheme was doing it
23:09:44 <Rubidium> what and how goes wrong I don't know though
23:09:58 *** ChanServ sets mode: +v tokai
23:10:22 <Wizzleby> Well, its a combination of fairly old code (as I understand it), and a fairly new set of modifications to the compiler's optimization scheme
23:11:14 <Rubidium> old (valid) code shouldn't just stop working
23:11:39 <Wizzleby> Rubidium: I agree, however this is not the first example of that happening that I've seen with gcc-4.5.0 :/
23:14:46 <Rubidium> so now the question is whether it's invalid code or invalid optimisation
23:17:27 <Rubidium> though there is an disturbing number of valgrind warnings on grfcodec
23:17:52 <Rubidium> even on my already patched for valgrind warnings binary
23:18:28 <Wizzleby> Pending the reason being worked out, this does at least gives me a better option than restricting tests in opengfx
23:19:42 *** Devedse has joined #openttd
23:19:45 <Rubidium> although there seem to be less warnings if compiled with -O0
23:20:02 <Rubidium> (valgrind warnings that is)
23:20:33 <Rubidium> problem is that grfcodec is a bit in limbo because the developer doesn't seem to be working on it and patches aren't applied
23:21:01 <Rubidium> -O0 makes grfcodec considerably slower though
23:21:44 <Rubidium> Ammler: this discussion might help you with the grfcodec on opensuse factory problem
23:21:57 <Wizzleby> Well, I think I can use the toolchain-funcs eclass to only use -O0 if the user is using gcc 4.5
23:22:46 <Wizzleby> Rubidium: it may explain issues with Arch Linux users too (if/when those pop up), last I heard from a friend, they're using gcc-4.5.0 too
23:23:45 <Wizzleby> 4.5.0 is still hardmasked in Gentoo, so at least that also alleviates my concern about the test failure becoming widespread since the stabilization of grfcodec
23:41:43 <Wizzleby> well it certainly is slower with -O0, but it works, and passes tests even under gcc-4.5.0
continue to next day ⏵