Log for #openttd on 19th April 2012:
Times are UTC Toggle Colours
00:10:03  *** Pikka [] has joined #openttd
00:22:34  *** pugi [] has quit []
00:28:33  <Nat_aS> there should be an option to scrub specific things like industries and houses from maps without removing everything else
00:28:40  <Nat_aS> perhaps replacing them with markers
00:28:50  <Nat_aS> so you can swap newgrifs without breaking things
01:10:54  *** A5b6bbda7 [] has quit [Remote host closed the connection]
01:29:05  *** KritiK [] has quit [Quit: Leaving]
01:29:17  *** asdwdfghthr [] has joined #openttd
01:29:30  <asdwdfghthr> hey there
01:32:48  *** cypher [] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
01:39:46  *** asdwdfghthr [] has quit [Quit: ajax IRC Client]
01:55:07  *** HerzogDeXtEr1 [] has joined #openttd
02:01:46  *** HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
02:16:06  *** kkb110_ [~kkb110@NYUFGA-WLESSAUTHCLIENTS-03.NATPOOL.NYU.EDU] has quit [Ping timeout: 480 seconds]
02:18:07  *** kkb110_ [~kkb110@NYUFGA-WLESSAUTHCLIENTS-02.NATPOOL.NYU.EDU] has joined #openttd
02:43:16  *** LordPixaII [] has joined #openttd
02:43:16  *** Pixa [] has quit [Remote host closed the connection]
02:46:39  *** Elukka [] has joined #openttd
03:17:37  *** Zeknurn [] has quit [Ping timeout: 480 seconds]
03:29:43  *** KByte [] has joined #openttd
03:31:44  *** glx [glx@2a01:e35:2f59:c7c0:d58d:fe15:439b:adbb] has quit [Quit: bye]
03:51:53  <Nat_aS> hi
03:52:13  *** KByte [] has quit [Quit: Leaving]
04:12:58  *** Pinkbeast [] has quit [Quit: leaving]
04:14:37  *** Pinkbeast [] has joined #openttd
04:19:42  *** roadt_ [~roadt@] has joined #openttd
04:51:18  *** Eddi|zuHause [] has quit []
04:51:20  *** LordPixaII [] has quit [Read error: Connection reset by peer]
04:51:35  *** Eddi|zuHause [] has joined #openttd
04:52:15  *** Pixa [] has joined #openttd
05:11:28  *** supermop [] has joined #openttd
05:13:12  *** roadt_ [~roadt@] has quit [Ping timeout: 480 seconds]
05:14:46  *** telanus [~Barney_Er@] has joined #openttd
05:16:08  *** Penguin [] has joined #openttd
05:18:00  <Penguin> So I had million while upgrading normal rail systems to electric rail systems. Then all the sudden, it went down to 0,000. Any idea as to what might of happened?
05:21:44  *** fonsinchen [] has joined #openttd
05:24:02  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
05:34:33  *** LordPixaII [] has joined #openttd
05:34:33  *** Pixa [] has quit [Remote host closed the connection]
05:39:08  *** Zeknurn [] has joined #openttd
05:45:50  *** Pixa [~pixa@] has joined #openttd
05:50:59  <NGC3982> it sounds like you had set your trains to autoreplace to an electical engine
05:51:15  <NGC3982> and that might not have taken place until the corresponding depots where changed.
05:51:35  *** LordPixaII [] has quit [Ping timeout: 480 seconds]
05:51:37  <NGC3982> check your auto replace window.
06:00:22  <Penguin> Thank you
06:01:55  <Penguin> :D
06:02:50  *** Penguin [] has quit [Quit: ajax IRC Client]
06:04:54  *** Penguin [] has joined #openttd
06:05:45  *** Penguin [] has quit []
06:11:37  *** mahmoud [] has joined #openttd
06:17:57  *** Zuu [] has joined #openttd
06:19:18  *** kkb110_ [~kkb110@NYUFGA-WLESSAUTHCLIENTS-02.NATPOOL.NYU.EDU] has quit [Ping timeout: 480 seconds]
06:20:59  *** kkb110_ [] has joined #openttd
06:26:42  *** roadt_ [~roadt@] has joined #openttd
06:28:57  *** TGYoshi [~TGYoshi@] has joined #openttd
06:37:39  *** andythenorth_ [] has joined #openttd
06:42:24  <NGC3982> :-)
06:45:45  *** andythenorth_ [] has quit [Read error: Connection reset by peer]
06:58:06  *** petern_ [~petern@] has quit [Quit: Leaving]
07:03:57  *** Zuu [] has quit [Ping timeout: 480 seconds]
07:14:42  *** fonsinchen [] has quit [Remote host closed the connection]
07:16:28  *** roboboy [] has joined #openttd
07:35:54  <Rhamphoryncus> NGC3982: well done :)
07:36:28  *** supermop [] has left #openttd []
07:40:36  *** sla_ro|master [slaco@] has joined #openttd
07:44:33  *** roboboy [] has quit [Ping timeout: 480 seconds]
07:51:57  *** peter1138 [] has joined #openttd
07:52:00  *** mode/#openttd [+o peter1138] by ChanServ
07:58:46  *** oskari89 [] has joined #openttd
07:59:18  *** roadt__ [~roadt@] has joined #openttd
08:03:08  *** roadt_ [~roadt@] has quit [Read error: Operation timed out]
08:07:35  *** Arafangion [] has joined #openttd
08:23:46  *** pugi [] has joined #openttd
08:34:50  *** MNIM [] has quit [Remote host closed the connection]
08:38:36  *** oskari89 [] has quit []
08:41:20  *** TramOfDeath [] has joined #openttd
08:41:40  <TramOfDeath> 0hai.
08:42:13  <TramOfDeath> The issue with base music is still not fixed.
08:44:31  <TramOfDeath> base music not loading if it is in content_download. Even the packages that were downloaded by package finder.
08:45:09  <TramOfDeath> Any1 on? :(
08:46:37  <TramOfDeath> OFTC - more like AFKN
08:47:08  <TramOfDeath> </3
08:47:33  <TramOfDeath> OFTC - first-ever IRC graveyard
08:48:27  *** Firartix [] has joined #openttd
08:50:31  <TramOfDeath> base music downloaded by in-game downloader doesn't load unless moved from downloads to regular.
08:51:33  <Markk> You don't get an answer in about 5 minutes, and you declare the whole network dead?
08:52:10  <TramOfDeath> I am that quick-to-rage
08:54:45  <TramOfDeath> I need a quick fix for this ~@~ -ing bug!!!
08:55:15  <TramOfDeath> It's been 'round since... 1.02?
08:55:38  <Markk> Do you acctually listen to the music in OTTD?
08:56:43  <TramOfDeath> This isn't just for me, this is for keeping things working for OTTD on Puppy Linux.
08:56:51  <Eddi|zuHause> TramOfDeath: so if it's like this for 2 years, what's another few minutes going to kill you?
09:00:31  <TramOfDeath> On Linux, the only fix is to map content_download as the folder above it.
09:00:52  <TramOfDeath> but on Win32, no apparent fix exists.
09:03:31  *** TramOfDeath [] has quit [Quit: Metadata is the ultimate pigshit that ruins everything!]
09:09:21  <Ammler> you could also point him to fs
09:10:16  *** krinn [] has joined #openttd
09:11:12  <Ammler> though, as a packager of a linux distro, he should have known.
09:11:29  <krinn> hi guys, i see slowdown in openttd-1.2 title game screen, i was about to filebug it, but as i think you will ask a lot of infos, i was thinking i could answer them faster here
09:12:11  *** roadt__ [~roadt@] has quit [Ping timeout: 480 seconds]
09:12:54  <krinn> the slowdown are because cpu goes 100%, the problem is why cpu goes from 30% to 100% for nothing
09:13:54  <krinn> i don't notice this strangeness while playing the game, but i play small game... while debugging the ai, so i only see it in title screen, but this might hide another problem that could appears later in a real game
09:15:03  <Ammler> load the title game as normal save?
09:15:45  <krinn> default name/location of the titlegame please so i could load it to see ?
09:16:51  <Ammler> I would guess in <installdir>/baseset
09:17:12  <krinn> opntitle.dat <- ?
09:17:20  <Ammler> yep, rename to .sav
09:17:31  <Ammler> s/rename/copy/
09:18:29  <krinn> done, waiting a bit to see what happen
09:18:51  <planetmaker> krinn: still, please, file a bug report with the available info. Only that makes sure it's not forgotten
09:19:11  <krinn> ah yes also doing it
09:19:17  <krinn> planetmaker, will do then
09:19:33  <krinn> titlegame is too heavy for my cpu
09:19:46  <planetmaker> hm, really?
09:19:50  <krinn> yes
09:19:59  <krinn> 26405 krinn     20   0  154m 114m  16m R  27,9  3,8  24:37.60 openttd
09:20:09  <krinn> 26405 krinn     20   0  154m 114m  16m R  99,1  3,8  25:03.53 openttd
09:20:09  <krinn> 26405 krinn     20   0  154m 114m  16m R 100,1  3,8  25:06.54 openttd
09:20:09  <krinn> 2
09:20:18  <krinn> goes from 20% to 100%
09:20:22  <planetmaker> but all is fine when you start a new game on your own or load other (older) savegames of yours?
09:20:34  <krinn> on my tests yes
09:20:41  <planetmaker> hm :S
09:21:30  <krinn> and looking at company infos, 3 players with 40~ road vehicle and 2 trains is quiet low
09:22:22  <krinn> and a 4rd with 12 aircrafst... anyway low number of vehicle
09:24:20  <planetmaker> you're also taking about 1.2.0, right? Not trunk
09:24:38  <krinn> the strangeness is that right now using another savegame (one that was use in AI battle) with ~12 AI running and admiral AI is using 145 trains+171road+20aircrafts the cpu keep going at 30-40% and game is smooth
09:24:47  <krinn> yes 1.2.0
09:25:07  <krinn> and this savegame is 2048x2048
09:26:57  <krinn> it really looks like the titlegame is doing it only, really strange as no AI, newGRF and map is small
09:35:14  *** FLHerne [] has joined #openttd
09:43:49  *** FLHerne [] has left #openttd []
09:44:15  *** FLHerne [] has joined #openttd
09:46:38  <krinn> planetmaker, done, look at toyland.txt and titlegame.txt in
09:58:06  *** TWerkhoven[l] [] has joined #openttd
10:03:17  *** DDR [] has quit [Read error: Operation timed out]
10:08:47  *** xiong [] has quit [Ping timeout: 480 seconds]
10:09:24  *** peter1138 [] has quit [Ping timeout: 480 seconds]
10:11:53  <planetmaker> krinn: random shot in the dark, but how does it perform when you start it with ./openttd -b 8bpp-optimized ?
10:12:12  <krinn> answer in sec, restarting
10:12:31  <Eddi|zuHause> planetmaker: the other people in the forum that had similar issues that didn't have an effect
10:13:05  <planetmaker> then it's at least not my imagination that I've heart / seen the issue before :-)
10:13:10  <krinn> for now quiet an improvment, cpu is at 16%-17%
10:14:08  <krinn> looks like it fix the titlescreen, can't get over 19%
10:14:22  <krinn> i'll try loading it as savegame now
10:15:34  <krinn> ok higher, but still running smooth and low: near 25% max now
10:16:27  <planetmaker> compared to 85%
10:16:34  <planetmaker> that's *a lot*
10:17:17  <krinn> yes
10:17:44  <krinn> want the ouput as txt to compare ?
10:17:51  <FLHerne> Interesting, mine lags horribly with either blitter :?
10:18:05  <planetmaker> yes, please attach that there, too, krinn. It's valuable info, I think
10:18:11  <krinn> doing it
10:18:14  <planetmaker> thx
10:18:30  <planetmaker> just the titlegame, FLHerne or also others?
10:18:40  <FLHerne> Just the titlegame
10:18:55  <FLHerne> In the end, I just replaced it with another savegame
10:19:06  <planetmaker> and that fixes it?!
10:19:13  <FLHerne> For me, yes
10:19:18  <planetmaker> That's "funny"
10:19:30  <FLHerne> I tried loading the titlegame as a normal game, too :P
10:19:36  <FLHerne> That was fine as well...
10:19:47  * FLHerne doesn't get it
10:20:01  <planetmaker> you say only when used as titlegame it's eating CPU?
10:20:09  <krinn> look at blitter.txt file in the bug
10:20:09  <FLHerne> Yes...
10:20:17  <krinn> yes
10:20:28  <krinn> the huge save game with toyland doesn't make that
10:20:32  <FLHerne> It eats my CPU when zoomed out a lot, but most games do
10:20:42  <krinn> and openttd is handling a lot of vehicle in that one on a huge map
10:21:25  <planetmaker> hm, I see. Yes huge games eating cpu when zoomed out is normal
10:21:42  <krinn> i think a bug is hidding itself somewhere, why my cpu could handle toyland savegame and not the "easy" titlegame
10:21:56  <planetmaker> I *can* somewhat understand a difference between 8bpp and 32bpp
10:22:14  <FLHerne> I know it's normal to lag zoomed out. When I focus on the same area I can see on the titlescreen, it runs fine, though
10:22:26  <krinn> you want the ./openttd -b 8bpp-optimized version txt with toyland ?
10:24:04  <planetmaker> krinn: do I see that right that you disabled compile optimizations?
10:24:18  <krinn> from the gentoo patch, yes
10:24:52  *** drac_boy [] has joined #openttd
10:24:54  <drac_boy> hi
10:24:54  <planetmaker> uhm, why?
10:25:20  <krinn> i'm not quiet sure why the gentoo author has done this patch, but anyway look at cpuinfo, i'm a bit sure my cpu doesn't really need full optimizations to help it playing openttd :)
10:25:24  <FLHerne> drac_boy: hi
10:25:37  <krinn> hi drac_boy
10:25:53  <drac_boy> how're you flherne :p
10:26:05  <krinn> i can rebuild it without the patch if you feel its need
10:26:07  <FLHerne> drac_boy: Ok, thanks
10:26:08  <planetmaker> yes, I looked at your cpuinfo. It should perform significantly better than mine
10:26:32  <planetmaker> you could just check the generic binary, krinn
10:26:47  <planetmaker> easier :-)
10:27:15  <krinn> there are static link? i always fail at using them because shared and using old lib versions most binaries distrib use
10:27:24  <planetmaker> it should be, yes
10:27:44  <drac_boy> what doing flherne? :)
10:28:01  <planetmaker> the linux generic binaries
10:28:05  <planetmaker> The others might not, krinn
10:28:38  <krinn> going to try it too, but the going to 100% isn't really because lack of cpu optimization imo
10:29:04  <FLHerne> drac_boy: I'm about to get on with some work...
10:29:22  <drac_boy> heh have fun with that then flherne
10:29:45  <planetmaker> I'd actually be surprised there, too, krinn :-)
10:30:09  <planetmaker> but it's easier to compare :-)
10:30:36  <krinn> lol, damn, missing GRF, wait a few adding them
10:31:13  <planetmaker> uh... you don't have them in you global folder ~/.openttd ?
10:31:39  <planetmaker> makes this stuff so much easier ;-)
10:31:50  <krinn> no, i have put them in my shared folder so all users have them
10:33:17  <planetmaker> but... how can you then have missing etc... ?
10:33:24  <krinn> no, it looks the same, goes from 22% to 68.2%, might goes 100% soon with generic binary
10:33:38  <krinn> here we are, 97,5%
10:33:39  <planetmaker> right
10:34:23  <krinn> same behavior but i have just run it with ./openttd (so it should have catch my ~/.openttd/openttd.cfg that is still set with my blitter)
10:36:26  <krinn> lol but the toyland test is now at 20-24%, better than my 30-40%, i should build openttd with optimizations back on :) (nice build that generic!)
10:39:05  <telanus> Am I missing something: ? I've upgraded to opengfx0.4.4
10:40:30  *** peter1138 [] has joined #openttd
10:40:34  *** mode/#openttd [+o peter1138] by ChanServ
10:47:11  <drac_boy> krinn btw what cpu do you have?
10:47:48  <krinn>
10:51:50  <drac_boy> why can't you just tell me?
10:52:15  <FLHerne> Because he has a link that tells you in more detail :P
10:52:29  <krinn> because i would need to remember it and i don't really care, why can't you click ?
10:54:50  <drac_boy> FLHerne problem is its not a link :p
10:55:07  <FLHerne> It looks like one from here...
10:55:20  <krinn> for drac_boy and poor users with lame irc chat program : model name	: Intel(R) Core(TM) i7 CPU         950  @ 3.07GHz
10:55:37  <drac_boy> krinn..its nothing to do with you not know what an actual web browser is ;)
10:55:54  <drac_boy> for it to take up that much of a cpu
10:56:11  <krinn> no idea, i could open the link with lynx too, it's just your irc program that cannot see a link and handle it
10:56:38  <drac_boy> krinn I said its nothing to do with irc
10:58:15  <krinn> it take only that much of a core, not the cpu, and it is why i think something is weird there
10:58:36  <drac_boy> weird indeed perhaps
10:59:31  <Ammler> krinn: maybe accidentially using a core, which is also already used by something else? or is openttd really using the whole core alone?
10:59:50  <Ammler> hmm, os should handle that
11:00:50  <krinn> could be that yes, but the balancing is quiet effective on that system
11:01:08  <krinn> in fact, except inside openttd i couldn't notice something is happening
11:01:17  <Rhamphoryncus> telanus: I get that too.  No idea what to do about it
11:01:28  <telanus> ok thanx
11:02:21  <telanus> thought I was doing something wrong
11:03:04  <Rhamphoryncus> I just ignored it.  Which was particularly annoying since I spent around 50 attempts to generate a map I liked and it popped up each time
11:04:20  *** peter1138 [] has quit [Read error: No route to host]
11:05:19  <telanus> I only get it when starting openttd
11:07:13  <Ammler> krinn: if you use gentoo package, you should report it there or try to reproduce the issue with upstream package
11:08:05  <krinn> Ammler, will do when the package hit the tree, i use a local overlay to build it
11:08:20  <krinn> and the issue still happen with generic binary
11:09:17  <Rhamphoryncus> telanus: It showed up every time I went back to the menu
11:09:22  <Ammler> if you use gentoo, you should also be able to build it self :-)
11:09:51  <krinn> that's what i have done Ammler i just reuse the previous ebuild to made it easy
11:10:05  <Ammler> which might have buggy config/patches
11:10:08  <Eddi|zuHause> krinn: try attaching a gdb to the process, and stop it at random points, then see where the backtrace is. or make a "make run-prof" [or similar] to get a profile
11:10:55  <krinn> Ammler, hence i have post the gentoo patch, but it still happen now i have remove it and rebuild it, and still with generic binary, so the patch isn't really a problem
11:11:29  <Ammler> also default config?
11:12:14  <telanus> Rhamphoryncus: seems your right. I never really go back to menu :D
11:12:17  <krinn> using the one i provide in the bug report
11:14:12  <krinn> Eddi|zuHause, tried to break when cpu goes mad : Program received signal SIGINT, Interrupt.
11:14:12  <krinn> 0x08180148 in Blitter_32bppOptimized::Encode(SpriteLoader::Sprite*, void* (*)(unsigned int)) ()
11:14:37  <krinn> cpu was at 75.2%
11:14:45  <Eddi|zuHause> krinn: and if you increase the sprite cache?
11:15:08  <krinn> must be in openttd.cfg right ?
11:15:10  <Ammler> hmm, the text file viewer: why is the button called "view readme", but the other just "changelog"?
11:16:28  <krinn> max_sprite_cache_size = 64
11:16:35  <krinn> this one Eddi|zuHause ? to what new value ?
11:16:45  <Eddi|zuHause> anything that is larger :)
11:16:54  <krinn> 128 so
11:17:00  <Eddi|zuHause> it's in MB
11:18:13  <krinn> it goes from 21.3% to 86.2% with 128 set
11:19:54  <krinn> i get max 93.5% now, this is better, but still high
11:20:01  <planetmaker> telanus, Rhamphoryncus you are using the current nightly, right?
11:20:14  <planetmaker> Then it's missing 4 sprites which indicate the happyness of a town with your service
11:20:36  <Eddi|zuHause> krinn: then try something ridiculously large
11:20:39  <Rhamphoryncus> updated openttd a day ago
11:20:52  <planetmaker> (and we still interestingly support in trunk the TTD base set while we do not do that with the open-source alternatives
11:21:38  *** Sludge321 [] has joined #openttd
11:22:20  <krinn> i've set it to 2048 (i have 3096 only) now 12 to 14% really improving the result !
11:22:47  <Ammler> krinn: meant the configure
11:23:02  <krinn> i mean 2048 in max_sprite_cache
11:23:39  <Sludge321> Hi all. Any tips on how to install 1.2.0 on Ubuntu 12.04 - I'm getting "Dependency is not satisfiable: libicu44 (>= 4.4.1-1)" when trying to use the Oneiric package.
11:23:41  <krinn> it can't never reach 20% with titlescreen running with it set to 2048
11:24:12  <Eddi|zuHause> so... we needs something to resize the sprite cache...
11:24:36  <krinn> yes, my default (but it's an old old openttd.cfg) was set to 64 and i think i never change it
11:25:25  <Ammler> it's 64 here too
11:25:28  <Ammler> no cpu issues
11:25:40  <Eddi|zuHause> krinn: people using 8bpp and no extra-zoom are never going to need that much, but people using 32bpp quickly run out, apparently
11:26:25  <Mazur> My sprite cache size is still on 4.
11:26:36  <Mazur> Which is was originally istalled with.
11:26:40  <Mazur> it
11:26:56  <krinn> my virtual eaten goes from 147M with 64 set, to 595M with 2048 set
11:28:39  <Mazur> O,wait, that was sprite-cache-size, not max_, which was 64.
11:30:10  *** HerzogDeXtEr1 [] has quit [Read error: Connection reset by peer]
11:31:40  <krinn> result using the 2048 max_sprite_cache
11:40:58  *** peter1138 [] has joined #openttd
11:41:01  *** mode/#openttd [+o peter1138] by ChanServ
11:42:18  *** roadt__ [~roadt@] has joined #openttd
12:00:22  *** petern [] has joined #openttd
12:00:25  *** mode/#openttd [+o petern] by ChanServ
12:07:50  *** peter1138 [] has quit [Ping timeout: 480 seconds]
12:12:50  *** petern is now known as peter1138
12:17:01  *** Rhamphoryncus [] has quit [Quit: Rhamphoryncus]
12:20:05  *** roboboy [] has joined #openttd
12:22:09  *** Pikka [] has quit [Quit: ChatZilla [Firefox 11.0/20120312181643]]
12:25:55  *** Sludge321 [] has left #openttd []
12:42:26  *** DanMacK [] has joined #openttd
12:44:51  *** glx [glx@2a01:e35:2f59:c7c0:3046:2b93:3f65:51db] has joined #openttd
12:44:54  *** mode/#openttd [+v glx] by ChanServ
12:52:42  *** DanMacK [] has quit []
12:54:58  *** roboboy [] has quit [Ping timeout: 480 seconds]
13:06:56  *** Kul [] has joined #openttd
13:07:37  *** Kul [] has left #openttd []
13:13:01  *** cypher [] has joined #openttd
13:19:49  <Belugas> hello
13:20:08  <drac_boy> hi
13:27:18  *** drac_boy [] has left #openttd [I'm done being in this room!]
13:30:08  *** oskari89 [] has joined #openttd
13:32:48  *** glx is now known as Guest926
13:32:48  *** glx_ [glx@2a01:e35:2f59:c7c0:3046:2b93:3f65:51db] has joined #openttd
13:32:49  *** mode/#openttd [+v glx_] by ChanServ
13:32:49  *** glx_ is now known as glx
13:38:35  *** Guest926 [glx@2a01:e35:2f59:c7c0:3046:2b93:3f65:51db] has quit [Ping timeout: 480 seconds]
14:01:42  *** TWerkhoven [] has joined #openttd
14:14:14  *** cypher [] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
14:26:29  *** peter1138 [] has quit [Read error: No route to host]
14:26:34  *** petern [] has joined #openttd
14:26:38  *** mode/#openttd [+o petern] by ChanServ
14:41:48  *** Jupix2 [] has joined #openttd
14:41:49  *** roadt__ [~roadt@] has quit [Ping timeout: 480 seconds]
14:42:00  *** andythenorth [] has joined #openttd
14:42:02  *** supermop [] has joined #openttd
14:43:00  *** zxbiohazardzx [] has joined #openttd
14:43:14  *** zxbiohazardzx [] has left #openttd []
14:44:49  *** goodger [] has joined #openttd
14:45:25  *** Jupix [~jupix@] has quit [Ping timeout: 480 seconds]
14:50:22  *** roadt__ [~roadt@] has joined #openttd
14:52:57  *** oskari89 [] has quit []
15:07:08  *** LordPixaII [~pixa@] has joined #openttd
15:07:16  *** flaa [] has joined #openttd
15:08:05  *** TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
15:11:15  *** HerzogDeXtEr [] has joined #openttd
15:13:08  *** Pixa [~pixa@] has quit [Ping timeout: 480 seconds]
15:21:25  *** Prof_Frink [] has joined #openttd
15:52:57  *** tokai|mdlx [] has joined #openttd
15:56:32  <planetmaker> <-- I guess we should offer this service, too
15:57:58  *** kaenkky [] has quit [Quit: d]
15:58:19  *** tokai|noir [] has quit [Ping timeout: 480 seconds]
15:59:23  *** Progman [] has joined #openttd
16:03:59  <andythenorth> offer custom consulting on the codebase too ;)
16:04:10  *** Xaroth_ [] has quit [Ping timeout: 480 seconds]
16:06:31  <planetmaker> yep. DaleStan set good example on the hourly rates ;-)
16:28:48  *** kaenkky [] has joined #openttd
16:43:24  *** supermop [] has quit [Quit: supermop]
16:48:01  <Terkhen> hello
16:50:00  *** andythenorth [] has quit [Quit: andythenorth]
16:50:38  <krinn> hi Terkhen
16:50:55  <krinn> anyone could explain the new destination too far on aircrafts ?
16:51:24  <krinn> it was working fine before, now i see that in orders
16:51:53  <planetmaker> krinn, aircraft can now have a maximum range
16:52:03  <planetmaker> Thus you cannot send it necessarily to every airport
16:52:12  <krinn> per vehicle type range or a global limit ?
16:52:22  <planetmaker> Also orders like A->B->C may fail, if C->A is too far
16:52:28  <planetmaker> it's a per-vehicle type limit
16:52:31  <planetmaker> NewGRF-defined
16:52:44  <krinn> hell
16:52:47  <planetmaker> default it doesn't exist
16:53:11  <krinn> why A->B->C fail because a->c too far? the aircraft will do ab then bc no ?
16:53:41  <planetmaker> Not sure what it does, if A->B and B->C is valid
16:53:50  *** andythenorth [] has joined #openttd
16:54:11  <krinn> <planetmaker> default it doesn't exist : it's an new option in config ?
16:54:17  <planetmaker> no
16:54:23  <planetmaker> It's a NewGRF property
16:54:34  <planetmaker> Either the NewGRF defines it. Or it doesn't
16:54:42  <krinn> ah ok, so it's no openttd that bug me, just another newGRF so :)
16:54:55  <planetmaker> probably only av8 :-)
16:55:02  <planetmaker> I know no other which uses it ;-)
16:55:18  <planetmaker> but an AI would want to support it
16:55:23  <krinn> that fucking newGRF is a hell for AI
16:55:29  <krinn> always something with it!
16:55:36  <planetmaker> lol
16:56:45  <planetmaker> no-one said it was easy ;-)
16:57:02  <krinn> specially this one !
16:57:16  <planetmaker> what makes it hard?
16:57:21  *** Xaroth [] has joined #openttd
16:57:45  <krinn> well, nothing, just that now my AI pickup aircraft  that are stuck at depot
16:59:30  <planetmaker> and should do the trick
17:00:01  <planetmaker> The same way that OpenTTD eveloves, NewGRF evolve. And of course AIs then have to evolve, too...
17:00:19  <planetmaker> And the API needs a new 1.2.0 link :-)
17:00:23  <planetmaker> the API docs
17:00:24  <krinn> yeah, but i just see the close point there
17:00:49  <krinn> checking airport->airport tile ok but then airport->depot tile of other airport just 1 tile too far = dead
17:01:22  <krinn> how great! now we will need all depot vs depot vs airport vs airport... combo
17:01:28  <planetmaker> check distance of airports
17:02:10  <krinn> yep, but i must enable a per route aircraft type handling
17:03:46  <krinn> how many AI will fail on this newGRF now, this also totally broke the compat files, as only AI that handle the new API will have a chance to react to it
17:03:55  <planetmaker> Probably all AIs
17:04:12  <krinn> lol i love your "probably"
17:04:23  <planetmaker> Road-only AIs will not fail
17:04:30  <planetmaker> nor ship-only
17:04:38  <krinn> until road newGRF put distance limit too
17:04:47  <planetmaker> that won't happen ;-)
17:05:02  <planetmaker> at least I see no reason to add such limit. While it makes sense for air
17:05:21  <andythenorth> ^^ same issues will occur with NoGo
17:05:26  <andythenorth> [just saying]
17:05:57  <planetmaker> Every add-on will face sometimes a situation where interaction with another add-on will change things it takes for granted
17:06:07  <planetmaker> and that's exactly what happens here
17:06:08  <andythenorth> is there ever any promise between AI and NewGRFs?
17:06:15  <planetmaker> There's no promise
17:06:19  *** Chris_Booth [] has joined #openttd
17:06:20  <andythenorth> so this is 'correct'
17:06:23  <andythenorth> rather than 'wrong'
17:06:39  <krinn> the real problem is newGRF take over AI
17:06:40  <planetmaker> AIs are only promised a "best effort" to make available all neccessary info via the API
17:06:49  <planetmaker> krinn, they don't
17:07:02  <planetmaker> The newgrf just implements something not available in earlier versions
17:07:18  <planetmaker> something the AI cannot know or have known before, true
17:07:18  <krinn> well i can't make an AI that wreck a newGRF even with newer API
17:07:23  <planetmaker> But it's by no means a take over
17:07:56  <planetmaker> of course not. But that's for the definition of the two:
17:08:00  <krinn> and the worst: it's just adding 1 byte to a newGRF to add that limit, but the handling for AI will get many guys mad
17:08:00  <planetmaker> NewGRF = game ressources
17:08:02  <planetmaker> AI = player
17:08:37  <planetmaker> so the player can never break the game. While the game can break with new rules and behaviour established playing style
17:08:54  <planetmaker> That's not surprising and nothing which even can nor should be changed
17:09:05  <planetmaker> NewGRFs' purpose is to change the way the game works
17:09:11  <krinn> any players (ok maybe not all) can bypass this easy, for an AI, need a rewrite
17:09:30  <andythenorth> it's a "nothing to see here" kind of issue
17:09:44  <andythenorth> filed under "some problems can't be solved"
17:10:04  <planetmaker> krinn, players cannot bypass that at all ;-) They can, similar to an AI, just choose to not play ;-)
17:10:24  <krinn> as of today, that newGRF will broke any AI using aircraft, that's just a fact
17:10:32  <planetmaker> yes
17:10:44  <krinn> a player will just dismiss the aircraft, until he have no other choice and remove the newGRF if this bug him too much
17:10:45  <planetmaker> That's why AIs declare an API version to be compatible with
17:10:52  <planetmaker> though that won't help here, either
17:10:55  <krinn> the AI cannot remove it
17:11:35  <planetmaker> yes, the AI could choose to ignore aircraft if it finds that the established methods don't work
17:11:43  <planetmaker> thus do the same a player does
17:12:02  <krinn> yes, but AI isn't adaptive to new event like that, like a human do
17:12:13  <planetmaker> this of course needs some meta knowledge analysing existing vehicles and stuff
17:12:24  <krinn> hence the AI rewrite to adapt it, not that easy
17:12:36  <planetmaker> yup. That's how it is
17:12:57  <planetmaker> Write it as a module or small library and all AI could profit ;-)
17:13:04  <krinn> and we never get benefits from newGRF nearly :(
17:13:09  *** frosch123 [] has joined #openttd
17:13:18  <krinn> i cannot query and set another livery/color for an engine per example
17:13:20  <planetmaker> what do you mean with "benefit"?
17:13:26  <andythenorth> AI is not afaict really considered when discussing newgrf specs
17:13:47  <krinn> and i saw extra stuff in newGRF, like different scheme of engine with diff power/spd and we can only use and get the default one
17:13:49  <andythenorth> if AI also had to accounted for, newgrf would basically go int stasis
17:13:56  <andythenorth> into /s
17:14:29  <krinn> i can't remember the name, but a newgrf for train provide diff spd/power of an engine you could switch too
17:14:34  <andythenorth> NARS 2
17:14:37  <krinn> something "benefits" for any players
17:14:42  <krinn> AI, no way
17:15:05  <planetmaker> not really. But it could need a flag of some kind for NewGRFs which reads "I break AIs of API <= x.y which use XXX"
17:15:37  <krinn> well, it could save a lot of AI, if something like this one happen again
17:15:41  <planetmaker> anyway, krinn, you're only doing destructive criticism.
17:15:48  <planetmaker> Constructive comments would be well more welcome
17:15:56  <andythenorth> AI authors need to maintain their stuff
17:16:01  <krinn> what do you expect ? i'm french, we're master at criticism
17:16:01  <andythenorth> as DaleStan once said
17:16:15  <andythenorth> "It behooves you to keep up to date in a fast-moving language"
17:16:16  <andythenorth> or so
17:16:21  <planetmaker> I expect constructive comments which help your situtations
17:16:35  <planetmaker> other than "NewGRFs suck, they may break my AIs"
17:16:39  <planetmaker> That's not going anywhere
17:16:53  <planetmaker> Nor is "NewGRFs must not implement new game-changing features" a solution
17:16:54  <krinn> saddly there's not, you took care already to provide needed stuff in the API so we could cry but not yell :)
17:17:02  <andythenorth> planetmaker: we *could* insist on backwards compatibility, same as for newgrf spec
17:17:10  <andythenorth> "you may not break existing AIs" ?
17:17:24  <planetmaker> andythenorth, but that means to not change the game rules
17:17:34  <planetmaker> which defies the purpose of new NewGRF features
17:17:51  <andythenorth> I said we could
17:17:55  <andythenorth> not that it's good
17:17:57  <andythenorth> :)
17:17:58  <planetmaker> same with new game script capabilities actually
17:17:59  *** Sacro [~ben@] has quit [Ping timeout: 480 seconds]
17:18:10  <krinn> at least, a little message in AI forum would have been nice to tell AI author about the new failure
17:18:14  <planetmaker> which might even pose a bigger challange actually for current AIs. No idea
17:18:35  <planetmaker> krinn, then please go ahead. No-one thought of that so far, I guess
17:18:57  <krinn> or no one see it yet no ?
17:19:10  <krinn> i have just discover it today
17:19:16  <planetmaker> not that I know. Not that it may mean that no-one noticed
17:19:25  <planetmaker> But not sure
17:20:51  <planetmaker> krinn, generally, the AI could use more attention. Also the AI interface within OpenTTD probably. But it always needs *someone* to do the work.
17:21:18  <planetmaker> Whatever that may actually be. Finding issues. Reporting issues. Notifying AI authors, writing AI API patches to add things needed,...
17:21:25  <planetmaker> and of course writing and improving AIs
17:21:33  <krinn> i know, i know, i couldn't help myself, else i would
17:21:46  <krinn> but sometimes it looks like newGRF goes too fast vs AI
17:21:47  <andythenorth> ha ha
17:21:53  <andythenorth> high contrast graphics ftw
17:22:03  <krinn> i'm still waiting a way to manage to remove a wagon from a train to place it on another one :/
17:22:34  <planetmaker> like players: separate it. Then add it to new train
17:22:46  <andythenorth> think of all the edge cases to handle there :o
17:22:52  <krinn> ehehe, except we can't click, once sperate the wagon ID is lost
17:22:55  <andythenorth> 'this train needs a brake van'
17:23:05  <andythenorth> 'this wagon can only be attached to train xyz'
17:23:15  <andythenorth> 'this train cannot have more than n wagons'
17:23:18  <andythenorth> :o
17:23:24  <andythenorth> it's a tough life for AI authors :)
17:23:49  *** zooks [] has joined #openttd
17:24:01  <krinn> yep andythenorth this wagon cannot be attach, you should have a look at my AI code to see how hard it is for an AI to handle
17:24:17  <andythenorth> have you tried 'worse is better' ? :)
17:24:47  <krinn> lol i'm scare already this name would be attach to a newGRF
17:25:07  <andythenorth>
17:25:12  <andythenorth> and
17:25:27  <andythenorth> specifically the example of how UNIX won by handling failures more bluntly
17:25:36  <andythenorth> dunno how it relates here, but it seems to
17:26:15  <andythenorth> planetmaker: fancy adding any FIRS translations?  Think there are updates....
17:28:04  <planetmaker> I might do later today
17:28:29  <krinn> planetmaker : that one from MoveWagon -> dest_vehicle_id 	The vehicle to move the wagon to, or -1 to create a new vehicle.
17:28:51  <krinn> until MoveWagon return the new ID, we're dead at switching engine/wagon from one train to another one
17:29:17  <krinn> and wagons remain lost in depot
17:29:26  <krinn> can't even erase them :/
17:30:01  <planetmaker> I'm not familiar enough with that part and the API. If you can't even delete them, it's definitely a bug, though
17:30:09  <planetmaker> But train building surely needs test building
17:30:16  <planetmaker> It also means that for me myself
17:30:29  <planetmaker> reading readme is for wimps ;-)
17:30:36  <krinn> :)
17:30:42  *** andythenorth [] has quit [Quit: andythenorth]
17:30:45  <planetmaker> except of course readme, section 4, line 191 ff
17:30:47  <planetmaker> :-P
17:30:51  <planetmaker> but I know that by heart
17:31:45  <krinn> as long as you don't get back the new vehicle ID, any functions of the API will need that vehicleID, so yes, wagons are lost in depot
17:32:03  <planetmaker> but you surely can check which vehicles are in the depot?
17:32:42  <krinn> yep, or some other tricky things, like i do, creating a dummy wagon so i get back it's vehicleID and attach wagons to it instead of a new vehicle
17:34:09  <krinn> except of course, sometimes the dummy wagon fail because of the "cannot attach..." :P
17:34:28  <krinn> told you planetmaker newGRF authors put all their efforts at bugging AI authors :)
17:34:45  <planetmaker> of course. Where would otherwise be the fun?
17:34:52  <krinn> ^^
17:35:51  *** andythenorth [] has joined #openttd
17:36:52  <planetmaker> omg... this can't be true... been chasing a "reference not found" for certainly half an hour... and all it needs is a s/fit/fig/ in some places. And I just didn't see it in plain sight
17:37:40  <andythenorth> it's bound to be in the last place you look ;)
17:37:42  <krinn> sed is your friend
17:38:29  <planetmaker> krinn, that doesn't help me to actually find the cause... once I knew, of course
17:39:04  <planetmaker> the bad thing was that the fig(ure) shows the fit :-P
17:39:09  <planetmaker> bad bad typo
17:41:00  <CIA-1> OpenTTD: translators * r24154 /trunk/src/lang/ (7 files): (log message trimmed)
17:41:00  <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
17:41:00  <CIA-1> OpenTTD: afrikaans - 53 changes by telanus
17:41:00  <CIA-1> OpenTTD: danish - 10 changes by mgarde
17:41:00  <CIA-1> OpenTTD: finnish - 12 changes by jpx_
17:41:01  <CIA-1> OpenTTD: lithuanian - 11 changes by Stabilitronas
17:41:01  <CIA-1> OpenTTD: brazilian_portuguese - 12 changes by Tucalipe
17:41:40  *** zooks [] has quit [Ping timeout: 480 seconds]
17:43:12  *** mal2 [] has joined #openttd
17:43:41  <andythenorth> planetmaker: I'm looking at
17:44:50  <andythenorth> I'm testing with 256x256 mountainous, rough, high sea
17:44:55  <andythenorth> - all the larger industries have issues occasionally
17:45:10  <andythenorth> - but the only pathological cases are quarry / clay pit - missing on every map so far
17:46:14  <Nat_aS> can you make an industry that can ONLY be placed on slopes?
17:46:26  <Nat_aS> because it would be cool if there was a quarry that was built into a hillside
17:48:25  *** frosch123 [] has quit [Remote host closed the connection]
17:48:49  <andythenorth> Nat_aS: yes, but it's too hard to place, so the game would rarely build it
17:48:59  <andythenorth> Pikka has it in PBI
17:50:00  <V453000> yeah there is always only a few on the map
17:51:07  <andythenorth> hmm
17:51:11  <andythenorth> come back frosch :P
17:51:44  <andythenorth> if industry was moved to 'something like NoGo', then the problem could be solved
17:52:15  <Nat_aS> well the idea is it would be an alternative sprite.
17:52:37  <Nat_aS> if there are no hillsides, it builds the flat version, if there are no flat spaces, it builds the hillside version
17:52:49  *** telanus1 [~Barney_Er@] has joined #openttd
17:53:13  <andythenorth> Nat_aS: you just get the flat one a lot :P
17:53:15  <andythenorth> or none
17:53:17  <planetmaker> andythenorth, invent a (much) smaller layout for them or one which fits slopes :-)
17:53:25  <andythenorth> the chances of finding exactly the right hillside is....low
17:53:30  <andythenorth> planetmaker: I'm thinking smaller layout
17:53:34  <planetmaker> yes.
17:53:36  <andythenorth> or break it into two components
17:53:40  <planetmaker> both. hillside + smaller
17:53:54  <andythenorth> hillside I've been avoiding for ages :P
17:54:01  <planetmaker> It's not like that we can easily add a dozen layouts, if it's modular enough
17:54:18  <Nat_aS> i guess you are right, because if you can't find a 6x4 flat area, you probably also won't find a 4 tile long straight hillside.
17:54:19  <andythenorth> modular is the problem
17:54:29  <andythenorth> a sloped 3x3 quarry means drawing 9 tiles
17:54:32  <Nat_aS> not with flat areas on both sides.
17:54:50  <andythenorth> @calc 9*16
17:54:50  <DorpsGek> andythenorth: 144
17:54:56  <andythenorth> but the combinations of different slopes means drawing at least 144 tiles iirc
17:55:01  <andythenorth> not happening
17:55:08  <andythenorth> george has done it for ECS though :P
17:55:21  <andythenorth> and it looks nice in ECS
17:55:25  <planetmaker> quite
17:55:36  <planetmaker> but why does it need 144 tiles?
17:55:44  <andythenorth> all the different slope combinations
17:55:46  <andythenorth> might be less
17:55:51  <andythenorth> I worked it out properly once
17:55:51  <planetmaker> there are 19 slopes
17:55:58  <andythenorth> might be more then :P
17:56:21  <andythenorth> suffice to say, it was lots
17:56:30  <planetmaker> @calc 19 * 5 + 19*4
17:56:30  <DorpsGek> planetmaker: 171
17:56:31  <andythenorth> although restricting to just, say \ view
17:56:34  <andythenorth> makes it easier
17:56:34  <planetmaker> :-P
17:56:52  <andythenorth> there's no point building on slopes on N side of map
17:56:57  <planetmaker> if you really want arbitrary placement, then it's 171
17:57:01  <planetmaker> why?
17:57:06  *** Alberth [] has joined #openttd
17:57:09  *** mode/#openttd [+o Alberth] by ChanServ
17:57:12  <andythenorth> I mean the rear face of a hill
17:57:15  <andythenorth> you won't see much :P
17:57:16  <planetmaker> why?
17:57:24  <andythenorth> maybe that's the *best* place to build them
17:57:30  <planetmaker> easy to draw
17:57:33  <andythenorth> ho
17:57:47  *** telanus [~Barney_Er@] has quit [Ping timeout: 480 seconds]
17:57:47  <Alberth> hu all
17:57:56  <Nat_aS> honestly though, I want to see more scenerios that use industry grfs
17:57:56  <planetmaker> hullo Alberth
17:58:01  <andythenorth> actually, the angle isn't so acute as I though
17:58:02  <andythenorth> t
17:58:06  <andythenorth> you would see most of the quarry
17:58:08  <andythenorth> hi Alberth
17:58:11  <Nat_aS> and hate random maps
17:58:22  <Nat_aS> so placing industries randomly is not something i care about :P
17:58:23  <planetmaker> Nat_aS, go right ahead and create them ;-)
17:58:25  <Alberth> andythenorth: you are painting for the wrong game :p
17:58:35  <planetmaker> not at all
17:58:39  <andythenorth> Alberth: would you prefer one with coasters?
17:58:53  <Alberth> RCT goes down at the back without showing any surface
17:59:28  <Nat_aS> I do however need good heightmaps though :P
18:00:04  <andythenorth> surely something 'like NoGo' (as discussed yesterday) would also enable terraforming on industry construction?
18:00:17  <andythenorth> basically, industry grf helper scripts
18:00:28  <Alberth> newgrf should give hints
18:00:41  <andythenorth> bundle a script in the tar with the newgrf
18:00:44  <Alberth> then I am sure openttd can manage without (no)go script
18:00:47  <andythenorth> have it handle the calls from the game
18:00:59  *** Chris_Booth [] has quit [Ping timeout: 480 seconds]
18:01:26  *** Chris_Booth [] has joined #openttd
18:01:31  <Alberth> or do you want the nogo script to perform terra forming?
18:01:40  <andythenorth> yes
18:02:21  <krinn> i love sed ! find . -name "*.nut" -print | xargs sed -i 's/AIOF_/OF_/g'
18:02:22  <Alberth> sounds like the wrong place to me, tbh
18:02:59  <andythenorth> it was a suggestion yesterday
18:03:05  <andythenorth> would also handle closures better....maybe
18:03:08  <andythenorth> maybe not actually
18:03:17  <planetmaker> wasn't the suggestion rather: create a mapgen API? :-)
18:04:22  <andythenorth> was it? :)
18:04:53  <andythenorth> hmm
18:05:05  <andythenorth> currently the clay pit / quarry require all tiles to be absolutely flat
18:05:25  <andythenorth> because foundations at the edges of it look stupid
18:05:34  <andythenorth> maybe it should use 2 tiles
18:05:48  <andythenorth> the centre tiles could be on slopes
18:06:31  <andythenorth> maybe not
18:07:27  *** Alberth1 [] has joined #openttd
18:07:27  *** Alberth [] has quit [Quit: Leaving.]
18:07:31  *** mode/#openttd [+o Alberth1] by ChanServ
18:07:31  *** Alberth1 is now known as Alberth
18:08:42  <Alberth> lol, SElinux killed the network manager for accessing a file, and it took down the connection as well :)
18:09:16  *** Chris_Booth [] has quit [Remote host closed the connection]
18:12:30  *** KouDy [~KouDy@] has quit [Quit: Leaving.]
18:13:20  <andythenorth> so...hints from newgrf to terraforming?
18:16:45  <Alberth> wouldn't that be better?
18:19:10  *** Wolf01 [] has joined #openttd
18:19:23  <Wolf01> helloink
18:19:33  <andythenorth> Alberth: maybe
18:19:45  <Alberth> oi Wolf01
18:19:45  <andythenorth> I should try and figure out if it solves the case
18:19:46  <Nat_aS> hey, when was the ability to join stations with the ctrl key removed?
18:20:00  <Alberth> Nat_aS: nope
18:20:11  <andythenorth> the problem is placing industries that need a large flat area
18:20:14  <Alberth> but it won't work if the stations are too far away
18:20:17  <Nat_aS> oh it's an option
18:20:24  <Nat_aS> was it always an option, or did that change?
18:20:42  <Alberth> no change recently there Nat_aS
18:21:14  *** petern [] has quit [Quit: Ex-Chat]
18:23:12  <Alberth> andythenorth: that's an extreme case, so you'd expect to get trouble in such cases
18:27:56  <andythenorth> Alberth: in that case the work of adding hints is probably tmwftlb
18:28:02  <andythenorth> it wouldn't be simple
18:28:08  <andythenorth> lots of varact 2 needed for them
18:28:26  <andythenorth> the issue is better solved by 'make smaller industries'
18:30:04  <Alberth> it is not a case of not having the right way of expressing what you want? "lots of varact 2" does not sound like a good way to express terra form wishes, to me
18:30:23  <andythenorth> I can't think of another :)
18:30:36  <andythenorth> it's all we have
18:30:59  <andythenorth> unless the industry layout def is extended in action 0
18:38:10  *** Zuu [] has joined #openttd
18:42:17  <andythenorth> bah
18:42:18  <andythenorth>
18:42:22  <andythenorth> new bug :|
18:42:30  * andythenorth has to go to the pub though
18:43:08  *** DDR [] has joined #openttd
18:43:21  <andythenorth> bye
18:43:22  *** andythenorth [] has quit [Quit: andythenorth]
18:43:36  *** DDR [] has quit []
18:43:56  *** DDR [] has joined #openttd
18:48:41  *** fonsinchen [] has joined #openttd
18:55:51  *** ffpp [] has joined #openttd
18:56:53  <ffpp> hi, I noticed the cargo payment rate drop-off diagram in the game and also read the wiki explaining that cargo loses value over time - but it said there that it loses value based on delivery time
18:57:40  <ffpp> are both factors for the actual payment value ? the delivery time penalty as described in the wiki + the drop-off in payment rates as stated ingame ?
18:58:00  <Rubidium> they're the same
18:58:29  <ffpp> hm, the diagram in the game looks way less harsh than the formula in the wiki sounds
18:58:51  <ffpp> or can this be altered by newgrfs ?
19:00:01  <Rubidium> looks are deceiving, and yes
19:07:30  *** Zeknurn [] has quit [Remote host closed the connection]
19:08:04  <Rubidium> also the graph in OpenTTD shows about 30% of the cargo payment range
19:08:12  *** Zeknurn [] has joined #openttd
19:09:01  <Rubidium> and that alone will significantly distort what you see
19:11:26  <ffpp> i know, the scale can distort the look of a graph
19:12:31  <ffpp> from the game mechanics wiki I got that the maximum penalty for a cargo payment is 88%. for passengers that are in transit for 200 days this penalty should apply
19:12:59  <ffpp> but the cargo payment rate graph shows a drop-off in ~50% for passengers over the span of 200 days
19:13:09  <ffpp> that's why I was wondering if there is a difference
19:14:27  <Rubidium> the maximum penalty applies after 255 'days'. I say 'days' because a 'day' for the cargo payment is actually 2.5 game days
19:14:46  <Rubidium> as described in the cargo income page on the wiki
19:15:19  <Rubidium> so the maximum penalty applies after about 637 days
19:16:51  <Rubidium> hmm, although... the slope's ofcourse different
19:18:43  <ffpp> ah, I didn't look at this page - on the game mechanics page was the talk of 0.4% penalty for each day being over the early delivery time, and the same for being over the late delivery time
19:21:52  <Rubidium> if my math is right, the lowest payment is after 124*2.5 days = 310 game days
19:22:39  <Rubidium> likewise after 200 days you'd be at 47% of maximum payment
19:23:32  <ffpp> sounds fitting
19:31:33  *** Rhamphoryncus [] has joined #openttd
19:34:53  *** ffpp [] has quit [Quit: ffpp]
19:36:15  *** Sacro [~ben@] has joined #openttd
19:38:37  *** fip [] has joined #openttd
19:42:25  *** Alberth [] has left #openttd []
19:46:43  <fip> Hi - I have a music problem where the music doesn't start inmediately (I am compiling the 1.2.0 version with a sdl_mixer patch) This worked in 1.1.5 - as far as I can see this is related to line 817 in openttd.cpp where is 0. It seems music settings are not read in yet at this point and this makes sense because between 1.1.5 and 1.2.0 some things changed in HandleSettingDescs in settings.cpp. Is this a known b
19:46:45  <fip> ug and is there a fix?
19:48:32  <Rubidium> it does start when the main menu is shown?
19:48:53  <Rubidium> i.e. after the NewGRF/content scan
19:49:53  *** drac_boy [] has joined #openttd
19:49:57  <drac_boy> hi
19:51:15  <fip> no, it doesn't start until the volume control in the music window is touched
19:53:30  <Rubidium> then will probably fix it, right?
19:56:39  <fip> thank's a lot: that looks very promising!
19:59:54  <fip> yup: success! :-)
20:02:04  *** peteris [~peteris@] has joined #openttd
20:03:24  * Rhamphoryncus accidentally sends his entire fleet for servicing x_x
20:03:38  <Rubidium> turn the undo knob!
20:04:06  <CIA-1> OpenTTD: rubidium * r24155 /trunk/src/openttd.cpp: -Fix: the music volume was set too early during startup; at a moment the configuration file wasn't read yet
20:08:15  <Rhamphoryncus> And even when I cancel the servicing they're already down the wrong path, so the depot is the "best" place to reverse
20:10:48  <drac_boy> heh
20:11:40  *** Biolunar [] has joined #openttd
20:15:56  *** frosch123 [] has joined #openttd
20:16:32  *** telanus1 [~Barney_Er@] has left #openttd []
20:26:06  *** bobfred [] has joined #openttd
20:26:59  *** bobfred [] has quit []
20:27:43  *** peter1138 [~petern@] has joined #openttd
20:28:16  *** Chris_Booth [] has joined #openttd
20:29:35  *** Progman [] has quit [Remote host closed the connection]
20:38:42  *** Miguelzinho [~Miguelzin@] has quit [Quit: Leaving]
20:42:31  <Zuu> @ports
20:42:31  <DorpsGek> Zuu: OpenTTD uses TCP and UDP port 3979 for server <-> client communication, UDP port 3978 for masterserver (advertise) communication (outbound), and TCP port 3978 for content service, a.k.a. BaNaNaS (outbound)
20:51:29  <Terkhen> good night
20:55:15  *** fip [] has left #openttd []
20:58:48  *** KritiK [] has joined #openttd
20:59:37  *** TWerkhoven[l] [] has quit [Ping timeout: 480 seconds]
21:05:19  *** Chris_Booth [] has quit [Quit: ChatZilla [Firefox 12.0/20120411064248]]
21:08:27  *** Firartix [] has quit [Ping timeout: 480 seconds]
21:13:35  *** MNIM [] has joined #openttd
21:14:08  *** frosch123 [] has quit [Remote host closed the connection]
21:15:24  *** fonsinchen [] has quit [Remote host closed the connection]
21:23:19  *** peteris [~peteris@] has quit [Quit: Ex-Chat]
21:24:21  *** Elukka [] has quit []
21:36:34  *** TGYoshi [~TGYoshi@] has quit [Quit: Popidopidopido]
21:40:34  *** goodger [] has quit [Ping timeout: 480 seconds]
21:42:30  *** flaa [] has quit [Quit: leaving]
21:52:45  *** FLHerne [] has left #openttd []
22:00:12  *** drac_boy [] has left #openttd [I'm done being in this room!]
22:17:39  *** cypher [] has joined #openttd
22:19:58  *** morten [] has joined #openttd
22:20:24  <morten> hi, is there enyone here?
22:21:23  <morten> i was wondering if there was someone who could help me install a server on my debian squezze server.
22:21:46  <morten> thanks
22:28:53  <peter1138> install it
22:28:54  <peter1138> run it
22:40:30  *** sla_ro|master [slaco@] has quit [Quit: DANGER is OFFLINE DANGER]
22:40:37  <morten> from where
22:40:52  <morten> trying to type: openttd -D
22:41:05  <morten> it doesen't exist
22:41:18  <morten> where do the file get installed?
22:41:38  <Eddi|zuHause> how did you "install" it?
22:43:37  <morten> dpkg -i
22:44:15  <morten> openttd-1.2.0-linux-debian-squeeze-i386.deb
22:45:39  <Wolf01> 'night
22:45:42  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
22:48:58  <morten> or do i have to have a server with a graphical gui
22:51:58  <Eddi|zuHause> your package manager then should have a way to tell you where the files ended up
22:52:07  <Eddi|zuHause> then you need to check whether that place is in your path
22:54:03  <krinn> if openttd is install-> whereis openttd and you'll get your answer
22:55:34  <morten> thanks, sry for being noob :P gotta learn somehow, hehe
22:56:33  <glx> if you want a build without GUI dependancy you need to compile it yourself
22:57:16  <morten> thought something like that now, it asked me for video driver
22:57:39  <morten> or, it says that it can't find graphic set
22:58:03  <glx> graphic set is always required
22:58:28  <morten>, can i use something from this site?
23:07:04  <heffer> i was always wondering if i can build a gui and non-gui version of openttd in one go?
23:07:27  <heffer> might be interesting for packaging
23:09:31  <Eddi|zuHause> i think that's tied too deeply into the code to make that possible. you have to run the compiler twice in any case
23:12:29  <morten> think this script could do. But again, im not any good.
23:15:06  <morten> good night, thanks for the help i have gotten
23:15:18  *** morten [] has quit [Quit: Lost terminal]
23:17:21  *** brambles [brambles@] has quit [Ping timeout: 480 seconds]
23:21:25  *** brambles [brambles@] has joined #openttd
23:23:28  *** KritiK [] has quit [Quit: Leaving]
23:25:46  *** LordPixaII [~pixa@] has quit [Ping timeout: 480 seconds]
23:27:21  *** Zuu [] has quit [Ping timeout: 480 seconds]
23:47:26  *** roadt__ [~roadt@] has quit [Ping timeout: 480 seconds]
23:50:08  *** mahmoud [] has quit [Ping timeout: 480 seconds]
23:53:58  *** mal2 [] has quit [Ping timeout: 480 seconds]
23:56:46  <Ammler> heffer: I do that for suse
23:58:18  <Ammler>

Powered by YARRSTE version: svn-trunk