IRC logs for #openttd on OFTC at 2010-02-14
⏴ go to previous day
00:09:14 <Rubidium> hmm, I must be using 7z incorrectly; it compresses worse than zip out-of-the-box
00:10:15 <ccfreak2k> Using the GUI or the command-line?
00:11:41 <Rubidium> just 7z a foo.7z <some files>
00:14:00 *** Frankr is now known as Guest2023
00:22:42 <ccfreak2k> There's all kinds of options you can change to increase compression.
00:22:53 <ccfreak2k> They're just not on by default it seems.
00:24:28 <aber> increase the dictonary size
00:26:28 <Rubidium> -mx9 and -ms=on doesn't make it smaller than zip -9 either :(
00:27:36 <ccfreak2k> You could also see if adding -mN=LZMA2 helps.
00:27:36 *** Phoenix_the_II has quit IRC
00:30:11 <ccfreak2k> I guess I read it wrong then.
00:30:34 <ccfreak2k> How much smaller is the ZIP archive from the uncompressed files?
00:30:43 <Rubidium> oh... "ultimate" settings
00:31:12 <Rubidium> ccfreak2k: ~1% or so IIRC
00:31:40 <ccfreak2k> In that case, I find it doubtful that LZMA will compress much better.
00:32:06 <ccfreak2k> That's a teeny bit over 0.5%.
00:32:08 <Rubidium> 198988411 7z with some 'ultra' setting
00:32:22 <Rubidium> 198450283 zip with -9
00:32:43 <aber> What's inside the archive?
00:32:59 <Rubidium> png and gzip compressed data
00:33:27 *** Eddi|zuHause has joined #openttd
00:33:30 * Lakie doubts you'd get much better with trying to store already compressed data.
00:33:56 <Rubidium> 198613830 <- 7z with lzma2
00:35:12 <Rubidium> Lakie: there are some tricks to compress it better; IIRC png uses gzip internally, so extracting that and running it through lzma might yield a 10-20% size reduction
00:35:41 <Rubidium> but... that's quite tricky and such
00:35:58 <gathers> are the png's optimized already?
00:37:01 <Rubidium> yeah, kinda. They can be optimised a bit, but... that's in the neighbourhood of 1%
00:40:53 <Rubidium> oh, I tried *all* I could find in my package manager
00:41:02 <Rubidium> one even tried like 200 different settings
00:43:34 <gathers> this might be a stupid question, but when bumping the savegame version number for new settings I add in a patch, do I have to bump SAVEGAME_VERSION as well? loading and saving seem to work even if I use higher numbers than SAVEGAME_VERSION in settings.h
00:44:17 <gathers> (I'd like for my branch to merge with cargodist without conflicts if possible)
00:44:25 <ccfreak2k> optipng will get you close to optimal. There's another one that can shave a few kilobytes off a 2000x2000+ image.
00:44:51 <Rubidium> yes; if the version in settings.h is higher than the savegame version it's just not stored in the savegame
00:45:21 <Rubidium> ccfreak2k: yeah, on a 2 MB PNG, so like 1%. Not really worth the effort :)
00:46:31 <ccfreak2k> I, personally, always use optipng. -zc9 -zm1-9 -zs0-3 -f0-5 doesn't take that long and always reduces final size, unless the image is small to begin with.
00:46:48 <gathers> ok, thanks. hmm, so another branch then I guess
00:54:50 *** KenjiE20|LT has joined #openttd
00:55:29 <Xaroth> i see #2 is going for the 'keepin it clean' award?
00:56:30 <ccfreak2k> The top three should be randomly chosen or cycled in-order on each game start.
00:58:58 <ccfreak2k> Or have a variety from different categories cycled RCT-tyle.
01:00:52 <Rubidium> but that would (unneededly) bloat the downloads
01:05:31 <gathers> Savegames have to be graded with integrals? Oh, I can see mathematicians having fun while voting on this :P
01:09:10 <Rubidium> hmm... yeah, always nice to have multiple meanings for a word
01:11:57 <aber> on the second savegame the crossing of canal and monrail, is it possible for the train to go through the water?
01:13:43 <Eddi|zuHause> <__ln__> can someone refresh my memory about what happened to Claire? <-- last appearance was in the shed with her and jacks father (christopher?) about one full season ago, then she just disappeared
01:13:57 *** Frankr is now known as Guest2029
01:14:48 <Xaroth> Rubidium: having the feature would still kick ass tho :o
01:15:37 <Xaroth> then again I would rather have it able to show multiple locations of 1 savegame
01:18:05 <Eddi|zuHause> Xaroth: there once was a patch that cycles through sign locations, or so
01:41:58 <Eddi|zuHause> __ln__: that's the scene where john looks for jacob, but finds these two instead, and then asks "how do i save the island?"
02:13:22 *** Dreamxtreme has joined #openttd
02:14:00 *** Frankr is now known as Guest2035
02:16:52 *** devilsadvocate_ has joined #openttd
02:16:53 *** devilsadvocate has quit IRC
02:57:31 *** roboboy has joined #openttd
03:14:08 *** Frankr is now known as Guest2043
03:25:48 *** rhaeder1 has joined #openttd
04:14:20 *** Frankr is now known as Guest2053
04:28:03 *** ChanServ sets mode: +v tokai
04:38:54 *** Gargami has joined #openttd
04:49:53 *** devilsadvocate_ has quit IRC
05:25:52 *** kd5pbo1 has joined #openttd
05:29:23 *** Maarten has joined #openttd
06:42:10 <SpComb^> BaNaNaS Name Change <-- I thought that would be asking about changing the name of Bananas...
06:52:30 *** kd5pbo1 is now known as kd5pbo
07:11:00 *** fonsinchen has joined #openttd
07:13:37 *** Terkhen has joined #openttd
07:32:36 *** Alberth has joined #openttd
07:33:16 *** roboboy has joined #openttd
07:50:30 *** Phazorx has joined #openttd
08:21:39 *** HerzogDeXtEr has joined #openttd
09:10:55 *** |Terkhen| has joined #openttd
09:20:25 *** Progman has joined #openttd
09:26:00 *** Terkhen has joined #openttd
09:53:23 <planetmaker> Rubidium: I assume that the votes are such that 0=least preferred and 10=most preferred title game, right?
09:54:22 <Phazorx> pm, any clue on coopers desync issues?
09:54:40 <planetmaker> I didn't do any desync debugging on it
10:01:03 <planetmaker> I could try, though ;-)
10:01:32 <planetmaker> let's see whether I can reproduce it locally
10:01:47 *** frosch123 has joined #openttd
10:02:27 <planetmaker> did you actually get a desync diff yesterday already?
10:02:45 <frosch123> i wrote it all in fs
10:02:54 <planetmaker> oh, I missed that then
10:03:45 <planetmaker> uh. That sounds ugly
10:04:33 <frosch123> the desync starts with a train choosing a a n vs. ne track right before the dropoff station which then causes the train to pick a platform 2 tiles to the nw, which then makes the train stop later, which then causes the electric spark to happen later, which causes the random seeds to differ :p
10:04:52 <planetmaker> he. random is defined re-defined often when compiling --enable-desync-debug
10:04:57 <Gargami> My bandwith is proportional to the height of my monitor.
10:05:06 <frosch123> but actually the yapf debug stuff is that broken, that the next run should be with valgrind
10:06:09 <planetmaker> In file included from ottd/trunk/src/ai/ai_config.cpp:15:
10:06:11 <planetmaker> ottd/trunk/src/ai/../core/random_func.hpp:88:1: warning: "Random" redefined
10:06:13 <planetmaker> ottd/trunk/src/ai/../core/random_func.hpp:17:1: warning: this is the location of the previous definition
10:06:22 <planetmaker> and many other files of course, too, where it is used
10:06:54 <planetmaker> well, yes, that's where I do compile...
10:06:58 <frosch123> i cannot remember getting those
10:08:08 <planetmaker> true. The :17 is __APPLE__ defined only
10:09:07 <Alberth> Gargami: turn your monitor 90 degrees :p
10:12:02 <Eddi|zuHause> __ln__: the episodes 4x10 and 4x11 are probably "interesting"
10:20:46 *** welshdragon has joined #openttd
10:21:31 <planetmaker> hm... is there a clean way to re-define a function?
10:22:11 <Eddi|zuHause> make an #ifndef __APPLE__ around the other one
10:29:38 <planetmaker> hm... the first definition is #define Random OTTD_Random - and OTTD_Random never appears anywhere.
10:30:22 <planetmaker> or do I grep wrongly or what does that line possibly do?
10:30:40 <planetmaker> I mean... when does that define play a role?
10:31:28 <peter1138> it replaces all future mentions of Random with OTTD_Random
10:31:36 <peter1138> thus, it doesn't then clash with apple's Random
10:32:41 <peter1138> you probably need #define OTTD_Random() on line 88 for apple
10:34:05 <planetmaker> I'll give it a shot, thanks
10:41:33 <peter1138> or perhaps comment out the first one
10:42:44 *** JVassie has joined #openttd
10:45:10 <planetmaker> your first proposal compiles without warnings
10:45:23 *** Hackykid has joined #openttd
10:45:27 <planetmaker> but the latter, too... Hm.
10:50:35 *** oskari89 has joined #openttd
10:55:05 *** Cybertinus has joined #openttd
10:56:13 <planetmaker> any good idea how to quickly test what is preferred? E.g. what could go wrong, what errors I should look for?
11:01:07 <Eddi|zuHause> planetmaker: if it clashes with a builtin random, then it may desync quickly
11:07:17 <Eddi|zuHause> "quakfrosch"... i haven't heard that phrase since i was 5 years old...
11:07:43 <frosch123> i hear it more often :p
11:10:17 *** roboboy has joined #openttd
11:10:26 <peter1138> planetmaker, which one works though ;)
11:10:47 <planetmaker> peter1138: in both cases the game starts just fine...
11:11:12 <planetmaker> but... just starting the game and loading a savegame doesn't look like a thorough test to me
11:11:59 *** Eddi|zuHause has joined #openttd
11:13:02 *** fonsinchen has joined #openttd
11:15:03 <peter1138> presumably, if you enabled random debug, you should be testing the functionality of that
11:16:26 *** Brianetta has joined #openttd
11:23:00 <planetmaker> If I remove the #ifdef __APPLE__ it needs to work in all cases. Funnily I am now connected to our anyway desyncing server. Without desync :-P
11:23:30 <planetmaker> and if a #ifdev __APPLE__ can be removed... that'd be nice
11:24:54 *** Phoenix_the_II has joined #openttd
11:27:00 *** Phoenix_the_II has quit IRC
11:27:06 *** Phoenix_the_II has joined #openttd
11:28:13 <Alberth> Eddi|zuHause: 'g' option is missing :)
11:29:20 <Eddi|zuHause> (i knew that was coming...)
11:31:59 <__ln__> Eddi|zuHause: correcto, it was 4x10 and 4x11
11:36:42 *** welshdragon has joined #openttd
11:38:43 *** |Jeroen| has joined #openttd
11:45:36 *** Coco-Banana-Man has joined #openttd
11:45:57 <planetmaker> frosch123: would it help to get more data on the desync issue?
11:46:17 <planetmaker> I could then try to have our server run in a version with --enable-desync-debug
11:46:18 <frosch123> planetmaker: you could try to reproduce it with yapf cache disabled :)
11:46:30 <planetmaker> is it a console setting?
11:46:38 <planetmaker> or does that need re-compile?
11:46:41 <frosch123> or you could fix the Dump stuff of yapf debugging which causes lots of invalid read, writes and segfaults
11:51:06 <frosch123> hmm, so valgrind is fine with everything up to "DumpState(pf1, pf2);"
11:51:37 <planetmaker> both patched should not be reproducable you say, but same thing, if only one is patched? We could give it a try
11:53:16 <frosch123> disabling the caching only on the client should desync just as well
12:00:25 *** KenjiE20 has joined #openttd
12:01:16 <planetmaker> Let's see. I can patch the server, too :-)
12:01:34 <planetmaker> Either I desync or not
12:01:45 *** SirSquidness has joined #openttd
12:02:24 *** SirSquid1ess has joined #openttd
12:02:45 *** SirSquid1ess has joined #openttd
12:04:21 *** SirSquidness has joined #openttd
12:06:44 *** roboboy has joined #openttd
12:07:04 <Rubidium> planetmaker: I reckon that 'old' SDKs used Random; that define has been there since r1 and I reckon it wouldn't be added if it wasn't needed
12:08:16 <planetmaker> Rubidium: I reckon that, too...
12:08:35 <planetmaker> frosch123: I don't seem to get a desync from the server while all others do ;-)
12:08:44 <planetmaker> patches on server and on my binary
12:08:52 *** Grelouk has joined #openttd
12:09:03 <frosch123> nice, now fix it properly :)
12:09:21 <planetmaker> well... as usual some others finally manage to join, too
12:11:24 <frosch123> int CDECL AddFormat(const char *format, ...) WARN_FORMAT(1, 2); <- wtf is wrong about that?
12:11:34 <frosch123> src/misc/str.hpp:103: error: format string argument not a string type
12:14:00 <Eddi|zuHause> desync in yapf cache? maybe railtype related?
12:15:59 <planetmaker> Eddi|zuHause: there are no rail types active in this game
12:16:25 <planetmaker> and the whole map uses only one (at least where trains drive)
12:17:16 <frosch123> since when do you use waypoints like in that savegame? i.e. without the actualy station order
12:19:02 <Eddi|zuHause> @openttd commit 10491
12:19:02 <DorpsGek> Eddi|zuHause: Commit by KUDr :: r10491 trunk/src/yapf/yapf_costrail.hpp (2007-07-09 18:57:12 UTC)
12:19:03 <DorpsGek> Eddi|zuHause: -Fix [FS#988, YAPF]: When rail segment was cached using electric engine and it ended with non-electric rail it was incorrectly cached with the end reason ESRB_DEAD_END instead of ESRB_RAIL_TYPE. (Eddi)
12:19:04 <DorpsGek> Eddi|zuHause: - It caused YAPF to end prematurely there when it was searching for another path (for non-electric engine).
12:19:05 <DorpsGek> Eddi|zuHause: - It can lead to sub-optimal path taken or 'train is lost' message.
12:19:06 <DorpsGek> Eddi|zuHause: - In MP game it can also cause desync.
12:19:19 <DorpsGek> Eddi|zuHause: Error: You haven't asked me a command; perhaps you want to see someone else's more. To do so, call this command with that person's nick.
12:19:44 <Xaroth> dorpsgek doesn't seem to like you, Eddi|zuHause :P
12:19:56 <frosch123> "Since non-static C++ methods have an implicit this argument, the arguments of such methods should be counted from two, not one, when giving values for string-index and first-to-check. " <- \o/
12:20:08 <planetmaker> Eddi|zuHause: also in principle ALL trains are the same here :-) We only transport wood ;-)
12:20:46 <Eddi|zuHause> planetmaker: but maybe there's a hint on how it might be solved...
12:20:59 *** KenjiE20 has joined #openttd
12:29:42 <peter1138> brrr, cold fniggers
12:31:21 *** Grelouk has joined #openttd
12:35:02 <Eddi|zuHause> you should visit that forum...
12:38:44 <Xaroth> that'd be so awesome with snow
12:48:18 <Eddi|zuHause> my neighbours have something similar, just below ground...
12:48:57 <Eddi|zuHause> and each time there is big rain, they have a huge problem...
12:54:30 *** _33joe_ has joined #openttd
12:55:56 <Rubidium> yes, but people don't react to those meta questions
12:57:24 <_33joe_> mám konkrétnu otázku : ako nastavím aby sa neaktívna spoločnosť ponúkla na predaj aktívnemu hráčovi
12:57:36 <_33joe_> I have a specific question: how to set up an inactive company offered to sell an active player
12:58:14 <planetmaker> if not bancrupt: none
12:58:31 <planetmaker> as admin you could delete it
12:58:33 <TrueBrain> you understood his questions? Kudos to you :)
13:00:07 <_33joe_> thts shame, i do not want to delete comapnies thats are good, bud has no players
13:00:33 <planetmaker> maybe they come back again?
13:00:49 <planetmaker> they'd be even more annoyed if someone swallowed their company, I guess
13:03:42 <Eddi|zuHause> _33joe_: you can remove their password and let someone else play
13:03:50 <Eddi|zuHause> but that is dangerous
13:04:20 <_33joe_> so I get an offer to buy only if the company's bankruptcy?
13:05:43 <_33joe_> :( there shuld by an option instead of autoclean to sell comapny to an active player
13:10:39 *** devilsadvocate has joined #openttd
13:54:16 *** ajmiles has joined #openttd
14:02:46 <planetmaker> that's with the random re-defined, e.g. the #ifdef removed, right?
14:03:02 <Eddi|zuHause> Quite Extraordinarily Dumb :)
14:03:08 <Rubidium> that's with random2.diff
14:03:46 <planetmaker> ok. So... better random1.diff?
14:05:28 <planetmaker> well. I could investigate to find out when random() deprecates... but that'd basically mean to combine both with a #ifdef <version>
14:05:57 <planetmaker> and why didn't I get the deprecation messages? :S
14:06:14 <Rubidium> 10.6 dropped everything "quick"?
14:07:09 <planetmaker> there are iirc still some quickdraw things there
14:07:22 <planetmaker> though quite a few got deprecated
14:08:34 <Rubidium> still, it's just 'not available' for x64
14:09:17 <planetmaker> that'd explain. Now you mention it: yes, I recall that I read somewhere in the docs they also not plan to make it available
14:10:34 <Rubidium> "Important: QuickDraw is deprecated in Mac OS X v10.5 and later. QuickDraw is not available for 64-bit applications."
14:11:44 <planetmaker> yeah. Thus not on my machine
14:12:12 <planetmaker> thus no conflict and deprecation message. Hm, interesting.
14:12:15 <Eddi|zuHause> hm... i should get the fast computer back... a video conversion job that took 20 minutes on the new one, takes 5 hours on the old one...
14:12:33 <planetmaker> So... random1.diff is it, I guess
14:12:44 <peter1138> stupid apple and their api game
14:12:58 <planetmaker> or would you say that it should check the target architecture?
14:17:51 *** Chris_Booth has joined #openttd
14:18:06 *** fonsinchen has joined #openttd
14:21:53 * Rubidium wonders why quickdraw hasn't been dropped already; seems like most of quartz already existed in 10.2
14:26:52 <Rubidium> oh, some sites claim quartz is extremely slow with the stuff 'we' do
14:28:20 <peter1138> we're all supposed to use opengl these days
14:36:20 <Lakie> Even for 2D, peter1138?
14:36:31 * Lakie thought openGL was more designed for 3D
14:36:50 <peter1138> you've never looked at the api
14:37:04 <Phazorx> coopers desync seems to be relevant to train unloading
14:37:11 <Phazorx> are tere any randomization in it ?
14:37:19 <Lakie> I've looked at some of it, such as the raster systems and such
14:37:38 <Phazorx> and when exactly does profit calculation happen (as in start of unload or when it actually is done?)
14:38:21 <planetmaker> Phazorx: look at the station. If the PF uses a random number, the train unloads at a DIFFERENT station
14:38:30 <planetmaker> so that's quite plausible to look for the reason in the PF
14:38:58 <planetmaker> but a check might only occur then later... when the train arrived
14:38:59 <Lakie> houldn't all random numbers be the same, or does openTTD not check random numbers in action executions?
14:39:15 <Phazorx> planetmaker: unlikely it is the case
14:39:30 <Rubidium> Lakie: should yes, a desync is when that 'should' doesn't hold
14:39:42 <Phazorx> when trains where stopped, that one was already half way into platform
14:39:49 <planetmaker> Phazorx: then I propose you do a desync debug as frosch did.
14:39:52 <Lakie> Thats true, uses that randomm number as the check doesn't it.
14:39:58 <Phazorx> planetmaker: i lack facility
14:40:09 *** KenjiE20 has joined #openttd
14:40:20 <Phazorx> mingw compiled oppenttd here crashes when i attach gdb
14:40:47 <peter1138> opengl is perfectly suited to 2D rendering... as long as all your images are powers of 2 :s
14:40:56 <planetmaker> you don't need gdb for desync debug. There's a wiki page describing what to do, Phazorx
14:41:10 <frosch123> Phazorx: the desync i debuged is a yapf/yapp cache problem which has nothing to do with unloading
14:41:12 <Lakie> Ah, that isn't true thogh, peter1138, tiles are 64x31 iirc...
14:41:13 <Phazorx> well my strtegy is also outdated then
14:41:15 <planetmaker> desync debug openttd tells you
14:41:48 <Phazorx> frosch123: which is why i am asking if randomization is used anywhere in that process
14:41:50 <planetmaker> as you need to compare client and server
14:41:59 <Phazorx> or there is something else happening which is not visible to me
14:42:12 <planetmaker> read that wiki page ;-) or compile with --enable-desync-debug
14:42:23 <planetmaker> and you'll know it all
14:42:43 <planetmaker> as it will tell you every single f***g random call
14:43:08 <peter1138> Lakie, and, well, that's just tiles. other sprites are all manner of different sizes
14:43:53 <frosch123> i.e. when the random difference is detected it is already too late
14:46:43 <frosch123> at your dropoff station you let trains first decide for platforms 1-3 or 4-6. yesterday there was a train which decided differently at that point on client/server
14:48:04 <frosch123> well, depending on join date it were different trains at different dates, but always one of the dropoffs
14:48:30 <Phazorx> frosch123: i was told that the ONLY possibility to detect a desync for ottd is random calls hence my desire to confirm that there is a randomization involved in unloading process (to me that would be strange)
14:49:12 <Phazorx> based on that i'd be able to beter approach the isse, since if the active train is not the reason for it - reason must be somewhere else and there is no point to mess with the unloading train
14:49:36 <frosch123> there is randomisation involved in unloading, e.g. trains can rerandomize their graphics when unloaded
14:49:41 <frosch123> but that is not the case here
14:49:58 <Phazorx> are you looking at current PSG too?
14:50:21 <frosch123> no, so did you encounter a desync again even with disable yapf cache?
14:50:59 <Phazorx> i'm not sure of pm "fixed" the server but i'd presume he did and it still desyncs
14:51:08 <Phazorx> however the case i am talking about is from yesterday
14:51:27 <Phazorx> when all activity was stopped and client joined fine as well as stayed w/o desyncing for a while
14:51:29 <frosch123> you also need to patch your client
14:51:47 <Phazorx> in attempt to figure out why, i sarted triggering trains one at time
14:51:53 <Phazorx> to see when people start dropping
14:52:33 <Phazorx> a particular case when a train, that was stopped half way into the platform, started unloading kicked everyone
14:52:40 <frosch123> anyway, i encountered only one type of desync with fs#3619
14:52:54 <planetmaker> Phazorx: I tested whether disabling the cache had a positive effect. All people desynced but myself (who I had the cache also disabled)
14:52:58 <planetmaker> I reverted the patch, though
14:52:58 <Phazorx> that looks like different one
14:53:10 <KenjiE20> pm; sucessfully tried it, but reverted, as it needs a patched client, which isn't much good for us..... ^ that
14:53:12 <Rubidium> Phazorx: the desync errors/kicks you get way after the actual desync happens
14:53:16 <Phazorx> planetmaker: did you rejoined after server was started?
14:53:30 <Phazorx> Rubidium: but only when there is something random
14:53:33 <planetmaker> well. Of course I have to join?
14:53:51 <Rubidium> Phazorx: unless a cache is incorrect
14:54:04 <Phazorx> planetmaker: if there are no server ticks between when you joined and when game started you wont desync
14:54:14 <Phazorx> so you have to rejoin after server starts going
14:54:23 <planetmaker> I wasn't first to join
14:54:28 <planetmaker> so there have been
14:54:41 <planetmaker> One other person desynced before I joined ;-)
14:54:57 <Phazorx> Rubidium Phazorx: the desync errors/kicks you get way after the actual desync happens<< which is why i AGAIN ask wether there is ANY randomization happening when train starts to unload
14:55:12 <fonsinchen> Is it known that the station view window does not cleanly shade?
14:55:24 <Rubidium> Phazorx: it isn't the randomisation that causes the desyncs!
14:55:35 <Rubidium> it's the randomisations that DETECT the desyncs
14:55:36 <Phazorx> Rubidium: but it is randomization that detects and kicks
14:56:02 <Phazorx> so it appeared to me that unloading train caused clients to get kicked
14:56:11 <Phazorx> which why i assume that it is the reason
14:56:22 <planetmaker> that's contradictory
14:56:24 <Phazorx> that assumption may only hold water if randomzation is used in ubloadin
14:56:50 <planetmaker> a tracer is not the cause
14:56:52 <Rubidium> it's probably more delivery to an industry
14:57:00 <Phazorx> it is inconclusive if you guys refuse to tell me if there is rnadomization on start of unload process :)
14:57:18 <planetmaker> Phazorx: because everyone would have to look it up, just as well you could do it.
14:57:20 <Phazorx> if you tell me there isnt - it's quite clear that the train is irrelevant
14:57:39 <Phazorx> Rubidium: does delivery to industry happens gradually?
14:58:30 <Phazorx> and i guess you imply that randomization is like between multiple possible destinations?
14:59:05 <Phazorx> pm: we have funky station design there btw
14:59:30 <Phazorx> each 4 platforms in group are from different stations, hooked to different sawmills
14:59:35 <planetmaker> Phazorx: did you read the flyspray ticket?
14:59:47 <Phazorx> planetmaker: the cache one?
14:59:50 <planetmaker> You might then have noted that I made that statement there already...
15:00:08 <planetmaker> No the one with the pink oranges...
15:00:19 <frosch123> the more intesting layout is actually, that the dropoff station is not part of the orders
15:01:31 <planetmaker> but indeed it would be worth mentioning that, too
15:02:51 <Phazorx> would be interesting to know what Chris Sawyer would think about SRNW design :)
15:03:27 <Eddi|zuHause> <peter1138> opengl is perfectly suited to 2D rendering... as long as all your images are powers of 2 :s <-- and what if you just add transparent pixels to all sprites?
15:03:41 <peter1138> Eddi|zuHause, you have to, yes
15:04:12 <ccfreak2k> And what if you use ARB_texture_non_power_of_two?
15:04:46 <Rubidium> I reckon that Apple doesn't want to support that
15:04:50 <Lakie> It doesn't garintue to work with stock opengl.
15:07:27 *** Grelouk_ has joined #openttd
15:07:33 <peter1138> anyway, we know plain opengl doesn't work with openttd
15:07:34 *** onemanbucket has joined #openttd
15:07:43 <onemanbucket> hello! is it alright to ask a noob question? :)
15:07:45 *** VictorOfSweden has joined #openttd
15:08:19 <onemanbucket> I'm trying to demolish a bus station, but I only get the message "Must demolish bus station first"
15:09:12 *** Intexon has joined #openttd
15:09:26 <planetmaker> do you use the road removal tool or the dynamite?
15:09:39 <planetmaker> e.g. bulldozer vs. dynamite? hm...
15:10:00 <onemanbucket> i think it's the latest one
15:10:03 <onemanbucket> i just downloaded it
15:10:03 <Rubidium> the bulldozer should work, the dynamite might not if the road's owned by someone else (IIRC)
15:10:09 <onemanbucket> and the bulldozer is greyed out
15:10:24 <Eddi|zuHause> you have to click "build station" before the bulldozer
15:10:40 <onemanbucket> Ah! that solved it
15:10:51 <Eddi|zuHause> the bulldozer turns "build XXX" into "remove XXX"
15:11:31 <onemanbucket> Didn't realize i had to select the build bus station command first
15:11:40 <onemanbucket> anwyay, now it works. thanks!
15:14:37 <ctibor> I have set pikkabird's basic industries parameter as pikkindw.grf = 1 in openttd.cfg according to wiki, to have food plant and brewery producing food in temperate, but it doesn't work. Industries still produce goods. Hasy anyone clue what the parameter should be?
15:16:26 <frosch123> if you do it in openttd.cfg it will only apply to new games
15:17:50 <ctibor> Just started new game and it still tells me, the same. Clicked on random Food processing plant and all I can see is goods
15:20:16 <planetmaker> ctibor: if you exited openttd, changes will probably have been overwritten
15:20:25 <frosch123> if you open the newgrf settings and select pbi: does it show the parameters in the infobox?
15:22:27 <ctibor> I see, i have old pbi version
15:32:46 *** [com]buster has joined #openttd
15:37:29 <ctibor> But now secondary industries are generated away from towns and cities...
15:40:20 <planetmaker> that's then how pikka wants it. It's a newgrf property to define where industries may be placed and where not
15:44:15 <ctibor> planetmaker: But it is definetely not placed according to the description on his wiki
15:53:00 *** welshdragon has joined #openttd
16:05:00 *** DJNekkid has joined #openttd
16:11:42 *** Boyinblue0 has joined #openttd
16:17:35 *** valhallasw has joined #openttd
16:25:13 *** Polygon has joined #openttd
16:25:25 *** SirSquid1ess has joined #openttd
16:48:01 *** Grelouk has joined #openttd
17:01:38 *** ajmiles2 has joined #openttd
17:03:24 *** Chillosophy has joined #openttd
17:14:24 *** Rexxars has joined #openttd
17:40:10 <Eddi|zuHause> hm. so my 5 hour job is now 3 hours in, 44% done and has 8 hours ETA...
17:40:44 <Hirundo> When compiling from hg source, I can't join network games (without modifications) since the revision string is different
17:40:53 <SpComb^> Eddi|zuHause: final_estimate = initial_estimate * pi
17:41:32 <Hirundo> Could this be changed, so the svn revision is read from the log (only if possible, of course) and used as revision string?
17:42:28 <Eddi|zuHause> SpComb^: in german we say "Pi mal Daumen" [pi times thumb] when something is an estimate ;)
17:42:51 * SpComb^ wonders how silly it would be to automatically tag each hg-svn commit with the svn rev number
17:43:26 <Eddi|zuHause> Hirundo: maybe you need to hack findversion.sh?
17:43:42 <SpComb^> well, findversion.sh already greps the hg log for the svn rev
17:43:55 <Eddi|zuHause> so why doesn't this work then?
17:43:56 <SpComb^> not sure if the revno is used anywhere in the build
17:44:04 <SpComb^> it's a separate output field
17:45:45 <Eddi|zuHause> hm.. that quote is not funny...
17:46:14 <Eddi|zuHause> especially when read out of context, it's just senseless brabble
17:46:20 *** Phazorx has joined #openttd
17:48:13 <frosch123> SpComb^: hg uses the svn revision for the "newgrf version"
17:49:43 <planetmaker> Hirundo, if you output REV instead of REV_NR in findversion.h, it should work. Might need a test whether it is actually a (modified) svn version.
17:50:01 <SpComb^> it's missing the r prefix, iirc :)
17:50:24 <planetmaker> The latter is a bit tricky. As there might be several (hg / git) commits in a local repo, so that e.g only the 8th oldest commit corresponds to a (valid) svn version
17:50:44 <SpComb^> indeed, then it isn't a clean trunk anymore
17:51:02 <planetmaker> SpComb^, yes. h for hg and g for git
17:51:02 <SpComb^> but, if you were to tag each incoming svn commit in the hg-svn repo with the rXXXX name, then it would... work
17:51:11 <TrueBrain> problem with hg: your 'hg tip' can be a SVN version, while it is modified
17:51:18 <TrueBrain> so using svn version is not safe
17:51:41 <TrueBrain> SpComb^: not really, only if you would merge 'properly' in such cases, which nobody will :p
17:51:44 <planetmaker> TrueBrain, the modified state can be determined the usual way.
17:51:54 <TrueBrain> planetmaker: modified, yes, if the commit is not committed
17:52:00 <TrueBrain> where that is the idea of a hg checkout
17:52:03 <planetmaker> But yes, there's the chance to 'fake' a commit message with the svn rXXX
17:52:17 <TrueBrain> it is not detectable if there is a difference between current tip, and svn version
17:52:23 <TrueBrain> planetmaker: not even fake
17:52:28 <SpComb^> talking about clean trunk checkouts in hg
17:52:35 <planetmaker> I once had a patch for that as it bugged me, too, that I couldn't join servers without explicitly giving the rev ;-)
17:52:55 <TrueBrain> SpComb^: the problem is in detecting this 'clean' checkout of hg
17:53:07 <planetmaker> TrueBrain, yes, I know, there's no way to tell. You only have you hg repo, sure
17:53:09 <Ammler> findversion.sh could detect if tip has a svn changset, then it isn't modified and could use svn rev
17:53:30 <planetmaker> Ammler, I could make commits myself which then would be detected as such
17:53:34 <Ammler> else they should be modifed anyway.
17:53:47 <TrueBrain> Ammler: as I said a moment ago, no, you cannot
17:54:03 <TrueBrain> the 'tip' being a svn commit does NOT guarantee the hg is unchanged (with respect to the SVN)
17:54:22 *** woldemar has joined #openttd
17:54:24 <planetmaker> I don't understand that argument of yours quite, TrueBrain
17:54:35 <planetmaker> hg and svn of OpenTTD are synced
17:54:36 <TrueBrain> I make a few commits
17:54:40 <Ammler> TrueBrain: but then somoene could need to make a commit with that in the message
17:54:43 <TrueBrain> the latest changeset can be a 'svn' commit
17:54:45 <TrueBrain> still, I have changes
17:54:54 <SpComb^> `hg id` will suffix a + if there are local modifications
17:55:18 <TrueBrain> there simply isn't a stable and always-correct method to make hg and svn in 'sync', network wise
17:55:37 <SpComb^> TrueBrain: if your tip is a commit from the openttd hg repo, it can't have any modifications in it...
17:55:49 <TrueBrain> there are very simple ways around that
17:55:51 <SpComb^> otherwise, it's a merge between the openttd branch and your custom stuff
17:55:57 <TrueBrain> which I used the first N months I used Mercurial, because I didn't know better :)
17:56:05 <TrueBrain> most people using Mercurial do not branch
17:56:08 <TrueBrain> they use the default to work in
17:56:18 <TrueBrain> after which a pull is applied on top of it
17:56:33 <SpComb^> won't it still end up being a merge commit as tip?
17:58:13 <planetmaker> uhm... but then those changes are not active, if you have more than one head, or?
17:58:28 <Hirundo> Isn't the parent revision of the working directory of more interest than the tip?
17:58:50 <TrueBrain> Hirundo: possible that gives more sane information
17:59:02 <TrueBrain> either way, tricky slope .. I would strongly advise to avoid such complexity
17:59:34 <planetmaker> hg parent is a good thing and better than tip, yes
17:59:55 <planetmaker> hg findversion uses it ;-)
18:00:20 <TrueBrain> (git btw is even worse in all this)
18:00:56 <SpComb^> `hg id` is the right thing to use
18:01:07 <SpComb^> "identify the working copy"
18:01:15 <Rubidium> hg/git repositories are made to ease development of external patches, not to use to build 'clean' trunk
18:01:52 <DorpsGek> planetmaker: Commit by rubidium :: r16462 trunk/findversion.sh (2009-05-29 21:24:51 UTC)
18:01:53 <DorpsGek> planetmaker: -Change [FS#2930]: use a safer way to detect the hash of a mercurial repository (planetmaker)
18:02:57 <SpComb^> isn't `hg id` available in old versions of mercurial, or why isn't that used?
18:03:05 <TrueBrain> hg id doesn't give enough information
18:04:01 <SpComb^> it should give you MODIFIED, REV, BRANCH
18:04:29 <planetmaker> SpComb^, it doesn't. Just the hash, if not tip
18:05:04 <Hirundo> ^^ it can show branches/tags/modifications
18:05:43 <planetmaker> question is: modifications with respect to what? To svn trunk will be difficult
18:06:18 <SpComb^> there can be two ids, but I guess that's only if there's an uncommited merge going on?
18:06:52 <TrueBrain> I hate the word 'parent' how mercurial uses it, it gives another suggestion to the function :p
18:07:23 <SpComb^> tip isn't relevant when dealing with "what's this checkout"
18:08:14 <planetmaker> hm, and we know how many revisions the trunk mercurial revision differs from the svn.
18:08:34 <planetmaker> thus we could see whether this repo has additional local commits
18:08:43 <TrueBrain> planetmaker: that only is true if you would have one branch
18:09:14 <TrueBrain> so then it only works with a full clean checkout, which makes it all completely useless anyway
18:09:26 <planetmaker> uhm... not really
18:10:30 <planetmaker> I could clone openttd trunk and get a version I can join servers with
18:10:46 <TrueBrain> still using subversion is more stable and sane in that case
18:10:51 <planetmaker> My modifications are anyway in other development repos ;-)
18:10:52 <TrueBrain> as Rubidium says, hg and git are only for development
18:11:01 *** Phazorx has joined #openttd
18:11:15 <TrueBrain> either way, even in that case I think you can do stuff ..
18:11:22 <TrueBrain> now I wonder about Mercurial
18:12:00 <Alberth> there are wonderfull rebase extensions for hg afaik
18:12:01 <TrueBrain> SpComb^: 'hg id -ibt' is useless :p
18:12:07 <TrueBrain> hg clone ... && hg update -r 14551
18:12:32 <Ammler> or simply change $REV to $REV_NR in findversion.sh...
18:12:36 <TrueBrain> oh, nevermind, 'hg diff' doesn't show new files :p
18:12:48 <TrueBrain> Alberth: hgqueues are much more sane :)
18:13:01 <Hirundo> Hmmm... my openttd crashes in the code that is supposed to help me debug another bug :S
18:13:29 <Alberth> TrueBrain: still looking for a versioned variant of that :)
18:13:40 <planetmaker> TrueBrain, hg diff does show them - if added. But then an existing file is also modified
18:14:02 <TrueBrain> patric@smallbrain:/prog/openttd/test2.hg$ hg diff
18:14:04 <TrueBrain> patric@smallbrain:/prog/openttd/test2.hg$ hg status
18:14:29 <planetmaker> Alberth, you can do that, versioned hg queues
18:14:32 <Hirundo> Alberth: it's perfectly possible to run your patches dir as a hg repo, effectively versioning it
18:14:42 <TrueBrain> a patch of a patch! WHOHO :p
18:15:08 <Hirundo> Indeed, interpreting the second derivative of the actual code can be a pain :)
18:15:12 <Eddi|zuHause> diffing diffs is funny ;)
18:15:16 <TrueBrain> something I refuse to do :)
18:15:27 <Alberth> sometimes it is useful
18:15:32 <Eddi|zuHause> you get a lot of rubbish when just the line numbers change
18:15:48 <SpComb^> there should be a diff tool for diffs
18:15:49 <planetmaker> TrueBrain, that's only valid for empty files
18:15:52 <Alberth> not so much to understand the changes but just to check there are none :)
18:15:56 <TrueBrain> planetmaker: still, wrong
18:15:59 <planetmaker> maybe also binary
18:16:14 <planetmaker> something which cannot be diff'ed properly
18:16:27 <planetmaker> But with a non-empty text file it shows diffs here of added files
18:17:19 <TrueBrain> why not for empty files?
18:17:21 <TrueBrain> at least tell about it?
18:17:25 <TrueBrain> it is a diff after all ..
18:17:34 <TrueBrain> (and yes, I do not agree with a lot of choices Mercurial has made :p)
18:17:53 <planetmaker> :-) WHY they chose to do that: dunno.
18:18:20 <planetmaker> Actually that's one of the things I didn't understand when I read about mercurial either
18:18:34 <planetmaker> as sometimes the filename itself can have a meaning
18:18:38 <Ammler> svn doesn't either, does it?
18:19:09 <TrueBrain> ===================================================================
18:19:28 <Forked> how did they compile the first compiler!?
18:19:41 <Forked> (I know, they wrote it in "machine code", you guys are no fun)
18:19:43 <TrueBrain> you really want an answer, or are you just trolling?
18:20:09 <Forked> hehe, I was at some point in life wondering :) I don't see it evolving like the chicken and the egg thing
18:20:10 <Eddi|zuHause> as opposed to the hen and egg problem, this really is an easy question :)
18:20:15 <TrueBrain> why would they have written it in machine code?!
18:20:36 <TrueBrain> punchcards for the win!
18:20:52 <Eddi|zuHause> of course before the compiler there was the interpreter
18:20:54 <Forked> don't bite! it was a non-relevant question. Sorry about the sort of trolling
18:21:12 <Eddi|zuHause> so you can implement a compiler in the interpreter
18:21:29 <TrueBrain> Eddi|zuHause: one could debate a punchcard reading is an interpreter :p
18:21:31 <planetmaker> hm.. what's the svn equivalent of hg forget?
18:21:43 <__ln__> of course they compiled the first compiler by saying "apt-get install build-essential" first!
18:21:47 <TrueBrain> planetmaker: good luck finding that :p Let me know when you do :) (except setting the ignore file)
18:22:03 <planetmaker> forget un-adds a file to be commited
18:22:22 <planetmaker> (but leaves the file itself untouched)
18:22:24 <TrueBrain> planetmaker: it is a bit stronger: it forgets about the file
18:22:46 <TrueBrain> (as in: it stops tracking it)
18:22:46 <SpComb^> planetmaker: hg del -R or such
18:22:57 <TrueBrain> but svn has nothing of the like
18:23:10 <TrueBrain> cp <file> temp.txt && svn revert <file> && mv temp.txt <file> :p
18:23:13 <ccfreak2k> If I invent some radically new traffic control structure in openttd, can I name it whatever I want?
18:23:28 <TrueBrain> ccfreak2k: no, it has to contain: Yet Another
18:23:54 <ccfreak2k> Then my next trick will be "Yet Another Widowmaker".
18:24:11 <planetmaker> well. revert did the trick (though it removed it, too) for the nasty test file I added :-P
18:24:25 <TrueBrain> svn is dumb, when it comes to such things
18:24:44 <SpComb^> or something, I can't remember :P
18:25:08 <TrueBrain> planetmaker: you can do: svn rm --keep-local :p
18:25:40 <planetmaker> he :-) good to know
18:27:39 <TrueBrain> Forked: but to educate you a bit: most old compilers were first written in an interpreter, not in machine code
18:28:17 <ccfreak2k> Alright, I think I finally have joystick input tuned.
18:29:24 <TrueBrain> lol, love reading the internet: the first compiler was a C-compiler <- BULLSHIT :p
18:29:30 <Eddi|zuHause> hm... shall i try to screw up my system by installing KDE 4.4?
18:29:40 <TrueBrain> (I feel a Q-Ball now)
18:29:52 * ccfreak2k is running KDE 4.4.
18:29:56 <frosch123> Eddi|zuHause: better switch to xfce
18:30:23 <SpComb^> pick up ion3 development
18:30:28 <TrueBrain> ccfreak2k: go sit in the corner now
18:30:35 <SpComb^> awesome is pretty annoying
18:30:45 <SpComb^> every time I download something with firefox, it completely messes up everything
18:30:46 * frosch123 uses xfce4 and kde4libs, but actually the kde4 tools in use (konsole and kate) are still screwed enough
18:31:10 <TrueBrain> frosch123: konsole? Why? Terminal (part of XFCE4) is much better/faster
18:31:14 <ccfreak2k> I don't use xfce, but I do think it's a nice tradeoff between *box and KDE/GNOME.
18:31:23 <TrueBrain> same for kate and the XFCE wordpad
18:31:53 <TrueBrain> I use kdelibs for okular (pdf viewer)
18:32:08 <frosch123> Hirundo: just wait some seconds :)
18:32:24 <frosch123> i need to cook up a message
18:32:35 *** ajmiles has joined #openttd
18:32:37 <ccfreak2k> If I wanted to pause the game in code in sdl_v.cpp, what would be the best way to do it?
18:32:41 <Eddi|zuHause> but i like the bloat of ktorrent, konversation, kmail, amarok and others...
18:32:58 <TrueBrain> I still have no alternative of konversion
18:33:14 * planetmaker gives additional salt and pepper to frosch123
18:33:24 <planetmaker> (for a tasty dinner) ;-)
18:33:40 <Eddi|zuHause> i deeply loathe dolphin...
18:33:43 <planetmaker> yes. Quiche is with eggs :-)
18:33:49 <planetmaker> I still have half of one.
18:34:07 <frosch123> Hirundo: try again :)
18:35:25 <Markk> It's Ubuntu with Gnome and Elementary Desktop on that (with Docky2).
18:36:59 <DorpsGek> TrueBrain: TrueBrain
18:37:03 <DorpsGek> TrueBrain: The operation succeeded.
18:37:17 <DorpsGek> TrueBrain: The operation succeeded.
18:38:02 <DorpsGek> Markk: I don't recognize you.
18:38:08 <DorpsGek> Commit by frosch :: r19134 /trunk/src/misc (3 files) (2010-02-14 18:33:57 UTC)
18:38:09 <DorpsGek> -Fix (r16983, r17219): YAPF debug output was quite broken.
18:38:17 <TrueBrain> till CIA is back :p
18:38:52 <frosch123> you broke .notice, i committed it only once :p
18:39:06 <TrueBrain> see you in court :p
18:43:22 <Eddi|zuHause> hm... and kaffeine still did not manage to get 1.0
18:45:35 <DorpsGek> Commit by translators :: r19135 /trunk/src/lang (6 files) (2010-02-14 18:45:24 UTC)
18:45:36 <DorpsGek> -Update from WebTranslator v3.0:
18:45:37 <DorpsGek> italian - 1 changes by lorenzodv
18:45:38 <DorpsGek> lithuanian - 2 changes by
18:45:39 <DorpsGek> norwegian_bokmal - 1 changes by mantaray
18:45:41 <DorpsGek> norwegian_nynorsk - 127 changes by mantaray
18:45:42 <DorpsGek> russian - 1 changes by Lone_Wolf
18:45:43 <DorpsGek> slovak - 199 changes by keso53
18:45:44 <DorpsGek> spanish - 1 changes by Terkhen
18:45:55 <planetmaker> Markk, that doesn't look like a linux desktop. Or is it?
18:46:12 <planetmaker> can you tell me which one?
18:46:23 <lennard> its a gnome with some skin and stuffs
18:46:23 <planetmaker> nice one. A clone of apple ;-)
18:46:27 <Markk> 07:34:09 PM < Markk> It's Ubuntu with Gnome and Elementary Desktop on that (with Docky2).
18:46:35 <planetmaker> ah, missed that, sorry
18:46:52 <lennard> the top panel is *very* recognizable :)
18:47:19 <Markk> Yeah, don't really like that panel, but can't really remove it.
18:47:20 <lennard> I don't know why you'd want to watch deal or no deal though... ;)
18:47:21 <planetmaker> lennard, not only the the top panel. Also the window decorations. And the app bar below
18:47:36 <lennard> planetmaker: the app bar is so not gnome
18:47:45 <lennard> not default anyway :P
18:48:00 <planetmaker> Well: I'm telling that it looks like my OSX :-) 1:1
18:48:01 <Markk> lennard: It's a MAD parody. :)
18:49:13 <Markk> (It comes with elementary desktop)
18:51:40 <Markk> Now: Buy some tacos/burritos or something. :)
18:52:08 <Markk> Eddi|zuHause: I'm veggie. :)
18:52:20 <Eddi|zuHause> they have vegetarian döner as well...
18:52:35 <Markk> Isn't döner dönerkebab?
18:52:47 <Eddi|zuHause> only when you add kebab ;)
18:54:28 <TrueBrain> yes .. that was clear to me too
18:59:01 <ccfreak2k> Going to use DoCommandP then./
19:04:44 <frosch123> TrueBrain: ok, Terminal does not have the first-row bugs of konsole. but you were not actually suggesting mousepad to me?
19:05:49 <TrueBrain> no, I was suggesting Editor
19:09:52 <frosch123> i cannot find something that matches "Editor". there are only mousepad and leafpad, and both do not qualify as editor to me
19:11:42 <Eddi|zuHause> yay kwin crashed on me and can't be restarted because of "segmentation fault"
19:11:45 <TrueBrain> not to program C, no, that is true :)
19:12:43 *** Grelouk has joined #openttd
19:13:56 <Eddi|zuHause> maybe i should move to australia
19:14:18 <planetmaker> don't. You might fall off the Earth
19:14:41 <planetmaker> everything's upside down there.
19:15:33 <frosch123> planetmaker: exactly, upside down, including gravity
19:30:28 *** VictorOfSweden has left #openttd
19:36:37 *** Bluelight has joined #openttd
19:44:45 *** Rhamphoryncus has joined #openttd
19:47:40 <TrueBrain> "Your IP is selected as possible winner"
19:47:57 *** Dreamxtreme has joined #openttd
19:50:03 <TrueBrain> it is like saying: this lottery ticket is selected as possible winner
19:50:19 <Eddi|zuHause> quick! install their program!
19:50:32 <planetmaker> and enter your bank account details.
19:50:59 <TrueBrain> how else are they going to pay me?
19:51:40 <Sacro> 'enter your phone number and we'll fax her to you'
19:51:51 <ccfreak2k> I ended up calling HandleKeypress().
19:51:57 <TrueBrain> oeh, and I can pause her!
19:51:58 <planetmaker> I'm somewhat sure I wouldn't want to touch theirs even with sanetary gloves and a long pike
19:54:04 <Zuu> Lol, took me until title game 7 to realize that the two images of each title game was not just different moments in time but also one with OpenGFX and one with original graphics. :-D
19:54:44 <planetmaker> There are even more than just two images ;-)
19:55:05 <Zuu> yea, for each resolution as well.
19:55:14 <planetmaker> makes kinda a difference
19:55:28 <planetmaker> Actually it's also interesting to listen to those games :-)
19:55:41 <Zuu> Im first giving 0-5 for the small one and then another 0-5 for how well they look in a big view.
19:55:59 <planetmaker> No points for feature-complete etc?
19:56:15 <frosch123> and negative points for bridges over the whole screen?
19:56:32 <planetmaker> long bridges? ;-)
19:56:57 <planetmaker> it's not necessarily bad. Depends IMO
19:58:07 <Zuu> The first 0-4 in 640x480 is mostly that they got all transport modes in screen and one extra if it looks good as well.
19:59:47 <planetmaker> :-) Well... I give also points for completeness in different rail types, signal types, drive-through vs. "normal" road stops, one-way streets and level-crossings closing on path signals ;-)
19:59:48 <frosch123> planetmaker: imo no part should be too big/dominant. so imo very long bridges, stations with 4+ platforms, long stretches of oneway-road, ... are bad :)
20:00:24 <planetmaker> frosch123, agreed :-) Still that doesn't exclude an ueber-long bridge. Just makes it less likely to fit
20:00:28 <ccfreak2k> Ok, zoom works too.
20:00:46 <ccfreak2k> I just need to add network support and figure out why writes are not being completed.
20:14:31 <frosch123> planetmaker: oh, and coop-style priority-signal cheating is also "bad" :)
20:15:50 <Eddi|zuHause> i should have finished my attempt...
20:15:58 <planetmaker> Lucky me, that I didn't use it.
20:17:39 *** oskari89 has joined #openttd
20:18:44 <planetmaker> Eddi|zuHause, the game for v2 :-P
20:19:39 <Alberth> Eddi|zuHause: when v2.0.0 is about to be released
20:20:04 <Eddi|zuHause> err... yes... certainly...
20:21:03 <Eddi|zuHause> hm... i don't know what i just did, but the estimate just went from "1:33" to "7:34" (hours)...
20:21:47 <planetmaker> you slowed down. Quite obviously
20:22:33 <DJNekkid> i got a technical question ...
20:22:59 <DJNekkid> Im makeing a "new tracks" set, with some "limited speed" rails ... cheaper slower, faster and more expensive ...
20:23:12 <DJNekkid> i got vehicles that are defined to use the "fastest" type...
20:23:20 <DJNekkid> but the "inbetweens" are not available to build...
20:23:37 <frosch123> see the railtopic, that problem has been discussed
20:23:48 <frosch123> afaik there is no solution yet :)
20:24:33 <DJNekkid> not a proposed one either?
20:24:57 <Eddi|zuHause> has it been discussed how to handle pathfinder penalties for "suboptimal" railtypes?
20:27:43 <rhaeder1> hi. what was the link for finding my own tickets I have reported? I have now reproduced one (if you remember, the lost trains while mass maintenance)
20:28:25 <planetmaker> my searches -> tasks I opened
20:29:25 <rhaeder1> but I found it. okay, it isn't that same bug :(
20:29:55 <planetmaker> hm, it shows only open tasks
20:33:07 <rhaeder1> uploading savegame now :)
20:41:11 <rhaeder1> happened temporarily :(
20:42:48 <Eddi|zuHause> # what shall we do with the sleeping kittens
20:43:15 <Rubidium> something with a shredder?
20:57:00 <Alberth> rhaeder1: I think you need more depots. I send all trains to a depot, and 3 trains didn't find one in time.
21:01:08 <frosch123> somehow nr.9 should be scrolled a bit more towards SE
21:09:36 <Sacro> Frankr: just watching from a distance (hull ;))
21:11:06 *** Grelouk has joined #openttd
21:12:28 <Alberth> rhaeder1: also, I cannot simply reproduce a lost vehicle message with current trunk, it seems.
21:15:43 <Rubidium> it's probably just a network where sending vehicles to a depot brings them in a place where they can't find their way back or so
21:18:30 <rhaeder1> Alberth: I had it only once popping up but didn't return :(
21:20:04 <Alberth> we need a save game that reliably reproduces the problem, otherwise we spend forever looking for the needle in a hay stack, if the needle even exists.
21:30:42 *** Frankr_ has joined #openttd
21:30:42 *** Frankr is now known as Guest2151
21:30:42 *** Frankr_ is now known as Frankr
21:45:22 <TrueBrain> feeding a pig bacon is wrong
21:46:37 *** welterde has joined #openttd
22:09:01 *** PeterT_ has joined #openttd
22:11:28 *** PeterT_ is now known as PeterT
22:21:33 *** Antigon has joined #openttd
22:29:25 <TrueBrain> damn, you guys are boring
22:29:51 * Prof_Frink puts down the power drill
22:30:14 <TrueBrain> that noise was ANNOYING
22:31:53 <Eddi|zuHause> you haven't heard that computer that i had...
22:32:05 <TrueBrain> I work in DataCenters
22:32:15 <TrueBrain> there is no noise your computer made that I haven't heard before
22:33:25 <TrueBrain> haha, doesn't work here :p
22:34:43 <valhallasw> although not having flash could be considered a good thing
22:34:55 <TrueBrain> lot of websites load MUCH faster :p
22:35:49 <valhallasw> the disavantage, of course, is not being able to appreciate the awesomeness of some TED talks
22:36:10 <TrueBrain> "Alle voordelen hebben nadelen"
22:36:37 *** Eddi|zuHause has joined #openttd
22:52:21 <Zuu> A bit annoying that you need to "patch" flash to make it work good in a dual screen setup. Still not an option to leave out as it is required to watch web-TV on swedish television.
22:56:41 <Eddi|zuHause> wait, they don't require silverlight? :p
22:56:41 <TrueBrain> that is a long time ago
22:56:59 <Zuu> The other option is to skip web-tv and get a real TV and pay the TV-fee and stick to the time table.
22:57:26 <TrueBrain> they really are that advanced over there? Impressive
22:58:00 <Eddi|zuHause> or the other other option is to fuck them and get the torrents...
22:59:38 <Eddi|zuHause> don't worry, almost everyone here once was here the first time...
23:00:19 <TrueBrain> I am still not sure about Eddi|zuHause
23:00:22 <PeterT> IPG: You were on the IS2 server before?
23:00:24 <TrueBrain> I think he was created with the channel
23:00:25 <Zuu> Eddi|zuHause: Who in here has not once been here before?
23:00:35 <PeterT> IPG: The IRC channel is #jonty
23:02:00 <TrueBrain> PeterT: stop stealing our users
23:03:02 <Zuu> Can't you two share the users?
23:03:22 <PeterT> Share?! With #openttd?!
23:03:25 <Eddi|zuHause> "he will join us or die!"
23:05:12 <IPG> yesterday I changed 51 strings in wt...
23:05:28 <PeterT> Oh, that's where I know you from!
23:05:40 <PeterT> I looked on the forums but couldn't find an "IPG"
23:05:51 <IPG> I'm Inga Papagaj on forum
23:06:05 <IPG> Cause I registrated years ago
23:06:11 <IPG> then, I was shortened to IPG
23:06:53 <IPG> Parrot is a type of lok in Hungary
23:07:28 <IPG> and the Inga means there is a controller car on the other end of the train, so you shoudn't deattach the lok when you are at the head station :)
23:08:30 <IPG> I changed some words to get more specifical....
23:09:20 <IPG> i think the words should be uniformal... so if we use a word to a thing, to the same thing use the same word, but an other thing use another
23:13:18 *** fonsinchen has joined #openttd
23:14:14 <PeterT> fonsinchen: What does the findstations patch do on your openttd.git repo?
23:16:48 *** PeterT_ has joined #openttd
23:19:25 <DJNekkid> dalestan: (or anyone else): Renum dont support Feature10 for action1 ... not hat it does for the others, but on this one it crashes
23:20:36 *** welshdragon has joined #openttd
23:20:58 <fonsinchen> I think it's outdated
23:21:27 <fonsinchen> The findstations patch petert is talking about
23:21:47 <PeterT> add a search to station window?
23:22:07 <fonsinchen> it's an optimization for the tile loop that has already been accepted in trunk
23:22:28 <DJNekkid> oh ... different discussion :P
23:35:08 *** Devedse has joined #openttd
23:37:13 *** Nite_Owl has joined #openttd
23:38:30 *** Phoenix_the_II has quit IRC
23:41:12 *** fonsinchen has joined #openttd
23:46:04 <PeterT> so fonsinchen, is it hard to update past the introduciton of zoom?
23:48:27 *** Grelouk_ has joined #openttd
23:49:16 <fonsinchen> I have an update ready. Just merging everything together right now.
continue to next day ⏵
