Back to Home / #openttd / 2012 / 04 / Prev Day | Next Day
#openttd IRC Logs for 2012-04-19

---Logopened Thu Apr 19 00:00:31 2012
00:17-!-Pinkbeast [damerell@chiark.greenend.org.uk] has quit [Quit: leaving]
00:19-!-Pinkbeast [damerell@chiark.greenend.org.uk] has joined #openttd
00:24-!-roadt_ [~roadt@60.168.82.215] has joined #openttd
00:56-!-Eddi|zuHause [~johekr@p5DC67BC3.dip.t-dialin.net] has quit []
00:56-!-LordPixaII [~pixa@79-68-104-75.dynamic.dsl.as9105.com] has quit [Read error: Connection reset by peer]
00:56-!-Eddi|zuHause [~johekr@p5DC67AD9.dip.t-dialin.net] has joined #openttd
00:56-!-Pixa [~pixa@79-68-104-75.dynamic.dsl.as9105.com] has joined #openttd
01:16-!-supermop [~daniel_er@cpe-67-250-2-219.nyc.res.rr.com] has joined #openttd
01:17-!-roadt_ [~roadt@60.168.82.215] has quit [Ping timeout: 480 seconds]
01:19-!-telanus [~Barney_Er@196.215.173.27] has joined #openttd
01:20-!-Penguin [430294e3@ircip1.mibbit.com] has joined #openttd
01:22<Penguin>So I had $33million while upgrading normal rail systems to electric rail systems. Then all the sudden, it went down to $600,000. Any idea as to what might of happened?
01:26-!-fonsinchen [~fonsinche@dslb-178-000-005-077.pools.arcor-ip.net] has joined #openttd
01:28-!-Prof_Frink [~proffrink@5e09ee84.bb.sky.com] has quit [Ping timeout: 480 seconds]
01:39-!-LordPixaII [~pixa@79-68-104-75.dynamic.dsl.as9105.com] has joined #openttd
01:39-!-Pixa [~pixa@79-68-104-75.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]
01:43-!-Zeknurn [~Zeknurn@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd
01:50-!-Pixa [~pixa@85.210.73.85] has joined #openttd
01:55<NGC3982>it sounds like you had set your trains to autoreplace to an electical engine
01:55<NGC3982>and that might not have taken place until the corresponding depots where changed.
01:56-!-LordPixaII [~pixa@79-68-104-75.dynamic.dsl.as9105.com] has quit [Ping timeout: 480 seconds]
01:56<NGC3982>check your auto replace window.
02:05<Penguin>Thank you
02:06<Penguin>:D
02:07-!-Penguin [430294e3@ircip1.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
02:09-!-Penguin [430294e3@ircip4.mibbit.com] has joined #openttd
02:10-!-Penguin [430294e3@ircip4.mibbit.com] has quit []
02:16-!-mahmoud [~KEM@ALyon-158-1-89-240.w90-29.abo.wanadoo.fr] has joined #openttd
02:22-!-Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has joined #openttd
02:24-!-kkb110_ [~kkb110@NYUFGA-WLESSAUTHCLIENTS-02.NATPOOL.NYU.EDU] has quit [Ping timeout: 480 seconds]
02:25-!-kkb110_ [~kkb110@cpe-69-203-124-125.nyc.res.rr.com] has joined #openttd
02:31-!-roadt_ [~roadt@60.168.82.215] has joined #openttd
02:33-!-TGYoshi [~TGYoshi@86.81.146.146] has joined #openttd
02:42-!-andythenorth_ [~andytheno@cpc23-aztw25-2-0-cust33.aztw.cable.virginmedia.com] has joined #openttd
02:47<NGC3982>:-)
02:50-!-andythenorth_ [~andytheno@cpc23-aztw25-2-0-cust33.aztw.cable.virginmedia.com] has quit [Read error: Connection reset by peer]
03:02-!-petern_ [~petern@217.64.121.52] has quit [Quit: Leaving]
03:08-!-Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds]
03:19-!-fonsinchen [~fonsinche@dslb-178-000-005-077.pools.arcor-ip.net] has quit [Remote host closed the connection]
03:21-!-roboboy [~robotboy@CPE-58-173-43-55.nxzp1.ken.bigpond.net.au] has joined #openttd
03:40<Rhamphoryncus>NGC3982: well done :)
03:41-!-supermop [~daniel_er@cpe-67-250-2-219.nyc.res.rr.com] has left #openttd []
03:45-!-sla_ro|master [slaco@95.76.26.172] has joined #openttd
03:49-!-roboboy [~robotboy@CPE-58-173-43-55.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds]
03:56-!-peter1138 [~petern@petern.bnsnet.co.uk] has joined #openttd
03:56-!-mode/#openttd [+o peter1138] by ChanServ
04:03-!-oskari89 [~oskari89@213-186-253-165.bb.dnainternet.fi] has joined #openttd
04:04-!-roadt__ [~roadt@60.168.94.103] has joined #openttd
04:07-!-roadt_ [~roadt@60.168.82.215] has quit [Read error: Operation timed out]
04:12-!-Arafangion [~Arafangio@220-244-108-23.static.tpgi.com.au] has joined #openttd
04:28-!-pugi [~pugi@host-091-097-069-005.ewe-ip-backbone.de] has joined #openttd
04:39-!-MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has quit [Remote host closed the connection]
04:43-!-oskari89 [~oskari89@213-186-253-165.bb.dnainternet.fi] has quit []
04:46-!-TramOfDeath [2e9fb4d9@ircip4.mibbit.com] has joined #openttd
04:46<TramOfDeath>0hai.
04:46<TramOfDeath>The issue with base music is still not fixed.
04:49<TramOfDeath>base music not loading if it is in content_download. Even the packages that were downloaded by package finder.
04:49<TramOfDeath>Any1 on? :(
04:51<TramOfDeath>OFTC - more like AFKN
04:51<TramOfDeath></3
04:52<TramOfDeath>OFTC - first-ever IRC graveyard
04:53-!-Firartix [~artixds@222.140.0.93.rev.sfr.net] has joined #openttd
04:55<TramOfDeath>base music downloaded by in-game downloader doesn't load unless moved from downloads to regular.
04:56<Markk>You don't get an answer in about 5 minutes, and you declare the whole network dead?
04:56<TramOfDeath>I am that quick-to-rage
04:59<TramOfDeath>I need a quick fix for this ~@~ -ing bug!!!
05:00<TramOfDeath>It's been 'round since... 1.02?
05:00<Markk>Do you acctually listen to the music in OTTD?
05:01<TramOfDeath>This isn't just for me, this is for keeping things working for OTTD on Puppy Linux.
05:01<Eddi|zuHause>TramOfDeath: so if it's like this for 2 years, what's another few minutes going to kill you?
05:05<TramOfDeath>On Linux, the only fix is to map content_download as the folder above it.
05:05<TramOfDeath>but on Win32, no apparent fix exists.
05:08-!-TramOfDeath [2e9fb4d9@ircip4.mibbit.com] has quit [Quit: Metadata is the ultimate pigshit that ruins everything!]
05:14<Ammler>you could also point him to fs
05:15-!-krinn [~krinn@114.54.71.86.rev.sfr.net] has joined #openttd
05:15<Ammler>though, as a packager of a linux distro, he should have known.
05:16<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
05:16-!-roadt__ [~roadt@60.168.94.103] has quit [Ping timeout: 480 seconds]
05:17<krinn>the slowdown are because cpu goes 100%, the problem is why cpu goes from 30% to 100% for nothing
05:18<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
05:19<Ammler>load the title game as normal save?
05:20<krinn>default name/location of the titlegame please so i could load it to see ?
05:21<Ammler>I would guess in <installdir>/baseset
05:21<krinn>opntitle.dat <- ?
05:22<Ammler>yep, rename to .sav
05:22<Ammler>s/rename/copy/
05:23<krinn>done, waiting a bit to see what happen
05:23<@planetmaker>krinn: still, please, file a bug report with the available info. Only that makes sure it's not forgotten
05:23<krinn>ah yes also doing it
05:24<krinn>planetmaker, will do then
05:24<krinn>titlegame is too heavy for my cpu
05:24<@planetmaker>hm, really?
05:24<krinn>yes
05:24<krinn>26405 krinn 20 0 154m 114m 16m R 27,9 3,8 24:37.60 openttd
05:24<krinn>26405 krinn 20 0 154m 114m 16m R 99,1 3,8 25:03.53 openttd
05:24<krinn>26405 krinn 20 0 154m 114m 16m R 100,1 3,8 25:06.54 openttd
05:24<krinn>2
05:25<krinn>goes from 20% to 100%
05:25<@planetmaker>but all is fine when you start a new game on your own or load other (older) savegames of yours?
05:25<krinn>on my tests yes
05:25<@planetmaker>hm :S
05:26<krinn>and looking at company infos, 3 players with 40~ road vehicle and 2 trains is quiet low
05:27<krinn>and a 4rd with 12 aircrafst... anyway low number of vehicle
05:29<@planetmaker>you're also taking about 1.2.0, right? Not trunk
05:29<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
05:29<krinn>yes 1.2.0
05:29<krinn>and this savegame is 2048x2048
05:31<krinn>it really looks like the titlegame is doing it only, really strange as no AI, newGRF and map is small
05:39-!-FLHerne [~francis_h@dsl-217-155-24-22.zen.co.uk] has joined #openttd
05:48-!-FLHerne [~francis_h@dsl-217-155-24-22.zen.co.uk] has left #openttd []
05:49-!-FLHerne [~francis_h@dsl-217-155-24-22.zen.co.uk] has joined #openttd
05:51<krinn>planetmaker, done, look at toyland.txt and titlegame.txt in http://bugs.openttd.org/task/5162
06:02-!-TWerkhoven[l] [~twerkhove@cpc3-linl7-2-0-cust522.sgyl.cable.virginmedia.com] has joined #openttd
06:08-!-DDR [~chatzilla@d99-199-14-2.bchsia.telus.net] has quit [Read error: Operation timed out]
06:13-!-xiong [~xiong@c-67-164-39-81.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds]
06:14-!-peter1138 [~petern@petern.bnsnet.co.uk] has quit [Ping timeout: 480 seconds]
06:16<@planetmaker>krinn: random shot in the dark, but how does it perform when you start it with ./openttd -b 8bpp-optimized ?
06:16<krinn>answer in sec, restarting
06:17<Eddi|zuHause>planetmaker: the other people in the forum that had similar issues that didn't have an effect
06:17<@planetmaker>then it's at least not my imagination that I've heart / seen the issue before :-)
06:17<krinn>for now quiet an improvment, cpu is at 16%-17%
06:18<krinn>looks like it fix the titlescreen, can't get over 19%
06:19<krinn>i'll try loading it as savegame now
06:20<krinn>ok higher, but still running smooth and low: near 25% max now
06:21<@planetmaker>compared to 85%
06:21<@planetmaker>that's *a lot*
06:22<krinn>yes
06:22<krinn>want the ouput as txt to compare ?
06:22<FLHerne>Interesting, mine lags horribly with either blitter :?
06:22<@planetmaker>yes, please attach that there, too, krinn. It's valuable info, I think
06:22<krinn>doing it
06:22<@planetmaker>thx
06:23<@planetmaker>just the titlegame, FLHerne or also others?
06:23<FLHerne>Just the titlegame
06:23<FLHerne>In the end, I just replaced it with another savegame
06:23<@planetmaker>and that fixes it?!
06:23<FLHerne>For me, yes
06:24<@planetmaker>That's "funny"
06:24<FLHerne>I tried loading the titlegame as a normal game, too :P
06:24<FLHerne>That was fine as well...
06:24*FLHerne doesn't get it
06:24<@planetmaker>you say only when used as titlegame it's eating CPU?
06:24<krinn>look at blitter.txt file in the bug
06:24<FLHerne>Yes...
06:25<krinn>yes
06:25<krinn>the huge save game with toyland doesn't make that
06:25<FLHerne>It eats my CPU when zoomed out a lot, but most games do
06:25<krinn>and openttd is handling a lot of vehicle in that one on a huge map
06:26<@planetmaker>hm, I see. Yes huge games eating cpu when zoomed out is normal
06:26<krinn>i think a bug is hidding itself somewhere, why my cpu could handle toyland savegame and not the "easy" titlegame
06:26<@planetmaker>I *can* somewhat understand a difference between 8bpp and 32bpp
06:26<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
06:27<krinn>you want the ./openttd -b 8bpp-optimized version txt with toyland ?
06:28<@planetmaker>krinn: do I see that right that you disabled compile optimizations?
06:29<krinn>from the gentoo patch, yes
06:29-!-drac_boy [~drac_boy@bas1-ottawa08-1177643171.dsl.bell.ca] has joined #openttd
06:29<drac_boy>hi
06:29<@planetmaker>uhm, why?
06:30<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 :)
06:30<FLHerne>drac_boy: hi
06:30<krinn>hi drac_boy
06:30<drac_boy>how're you flherne :p
06:30<krinn>i can rebuild it without the patch if you feel its need
06:30<FLHerne>drac_boy: Ok, thanks
06:30<@planetmaker>yes, I looked at your cpuinfo. It should perform significantly better than mine
06:31<@planetmaker>you could just check the generic binary, krinn
06:31<@planetmaker>easier :-)
06:32<krinn>there are static link? i always fail at using them because shared and using old lib versions most binaries distrib use
06:32<@planetmaker>it should be, yes
06:32<drac_boy>what doing flherne? :)
06:32<@planetmaker>the linux generic binaries
06:32<@planetmaker>The others might not, krinn
06:33<krinn>going to try it too, but the going to 100% isn't really because lack of cpu optimization imo
06:33<FLHerne>drac_boy: I'm about to get on with some work...
06:34<drac_boy>heh have fun with that then flherne
06:34<@planetmaker>I'd actually be surprised there, too, krinn :-)
06:34<@planetmaker>but it's easier to compare :-)
06:35<krinn>lol, damn, missing GRF, sample.cat... wait a few adding them
06:35<@planetmaker>uh... you don't have them in you global folder ~/.openttd ?
06:36<@planetmaker>makes this stuff so much easier ;-)
06:36<krinn>no, i have put them in my shared folder so all users have them
06:38<@planetmaker>but... how can you then have missing sample.cat etc... ?
06:38<krinn>no, it looks the same, goes from 22% to 68.2%, might goes 100% soon with generic binary
06:38<krinn>here we are, 97,5%
06:38<@planetmaker>right
06:39<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)
06:41<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!)
06:43<telanus>Am I missing something: http://img696.imageshack.us/img696/9292/clipboard02cvd.png ? I've upgraded to opengfx0.4.4
06:45-!-peter1138 [~petern@176-35-84-218.xdsl.murphx.net] has joined #openttd
06:45-!-mode/#openttd [+o peter1138] by ChanServ
06:51<drac_boy>krinn btw what cpu do you have?
06:52<krinn>http://bugs.openttd.org/task/5162/getfile/8309/cpuinfo.txt
06:56<drac_boy>why can't you just tell me?
06:57<FLHerne>Because he has a link that tells you in more detail :P
06:57<krinn>because i would need to remember it and i don't really care, why can't you click ?
06:59<drac_boy>FLHerne problem is its not a link :p
06:59<FLHerne>It looks like one from here...
07:00<krinn>for drac_boy and poor users with lame irc chat program : model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
07:00<drac_boy>krinn..its nothing to do with irc..do you not know what an actual web browser is ;)
07:00<drac_boy>i7...hm...interesting for it to take up that much of a cpu
07:00<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
07:01<drac_boy>krinn I said its nothing to do with irc
07:03<krinn>it take only that much of a core, not the cpu, and it is why i think something is weird there
07:03<drac_boy>weird indeed perhaps
07:04<Ammler>krinn: maybe accidentially using a core, which is also already used by something else? or is openttd really using the whole core alone?
07:04<Ammler>hmm, os should handle that
07:05<krinn>could be that yes, but the balancing is quiet effective on that system
07:05<krinn>in fact, except inside openttd i couldn't notice something is happening
07:06<Rhamphoryncus>telanus: I get that too. No idea what to do about it
07:06<telanus>ok thanx
07:07<telanus>thought I was doing something wrong
07:07<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
07:09-!-peter1138 [~petern@176-35-84-218.xdsl.murphx.net] has quit [Read error: No route to host]
07:10<telanus>I only get it when starting openttd
07:11<Ammler>krinn: if you use gentoo package, you should report it there or try to reproduce the issue with upstream package
07:12<krinn>Ammler, will do when the package hit the tree, i use a local overlay to build it
07:13<krinn>and the issue still happen with generic binary
07:14<Rhamphoryncus>telanus: It showed up every time I went back to the menu
07:14<Ammler>if you use gentoo, you should also be able to build it self :-)
07:14<krinn>that's what i have done Ammler i just reuse the previous ebuild to made it easy
07:14<Ammler>which might have buggy config/patches
07:14<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
07:15<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
07:16<Ammler>also default config?
07:16<telanus>Rhamphoryncus: seems your right. I never really go back to menu :D
07:17<krinn>using the one i provide in the bug report
07:18<krinn>Eddi|zuHause, tried to break when cpu goes mad : Program received signal SIGINT, Interrupt.
07:18<krinn>0x08180148 in Blitter_32bppOptimized::Encode(SpriteLoader::Sprite*, void* (*)(unsigned int)) ()
07:19<krinn>cpu was at 75.2%
07:19<Eddi|zuHause>krinn: and if you increase the sprite cache?
07:19<krinn>must be in openttd.cfg right ?
07:19<Ammler>hmm, the text file viewer: why is the button called "view readme", but the other just "changelog"?
07:21<krinn>max_sprite_cache_size = 64
07:21<krinn>this one Eddi|zuHause ? to what new value ?
07:21<Eddi|zuHause>anything that is larger :)
07:21<krinn>128 so
07:21<Eddi|zuHause>it's in MB
07:22<krinn>it goes from 21.3% to 86.2% with 128 set
07:24<krinn>i get max 93.5% now, this is better, but still high
07:24<@planetmaker>telanus, Rhamphoryncus you are using the current nightly, right?
07:24<@planetmaker>Then it's missing 4 sprites which indicate the happyness of a town with your service
07:25<Eddi|zuHause>krinn: then try something ridiculously large
07:25<Rhamphoryncus>updated openttd a day ago
07:25<@planetmaker>(and we still interestingly support in trunk the TTD base set while we do not do that with the open-source alternatives
07:26-!-Sludge321 [~matt@124-169-217-191.dyn.iinet.net.au] has joined #openttd
07:27<krinn>i've set it to 2048 (i have 3096 only) now 12 to 14% really improving the result !
07:27<Ammler>krinn: meant the configure
07:27<krinn>i mean 2048 in max_sprite_cache
07:28<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.
07:28<krinn>it can't never reach 20% with titlescreen running with it set to 2048
07:28<Eddi|zuHause>so... we needs something to resize the sprite cache...
07:29<krinn>yes, my default (but it's an old old openttd.cfg) was set to 64 and i think i never change it
07:30<Ammler>it's 64 here too
07:30<Ammler>no cpu issues
07:30<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
07:31<Mazur>My sprite cache size is still on 4.
07:31<Mazur>Which is was originally istalled with.
07:31<Mazur>it
07:31<krinn>my virtual eaten goes from 147M with 64 set, to 595M with 2048 set
07:33<Mazur>O,wait, that was sprite-cache-size, not max_, which was 64.
07:34-!-HerzogDeXtEr1 [~Flex@i59F6D81.versanet.de] has quit [Read error: Connection reset by peer]
07:36<krinn>http://bugs.openttd.org/task/5162/getfile/8311/2048.txt result using the 2048 max_sprite_cache
07:45-!-peter1138 [~petern@176-35-84-218.xdsl.murphx.net] has joined #openttd
07:45-!-mode/#openttd [+o peter1138] by ChanServ
07:47-!-roadt__ [~roadt@60.168.94.103] has joined #openttd
08:05-!-petern [~petern@petern.bnsnet.co.uk] has joined #openttd
08:05-!-mode/#openttd [+o petern] by ChanServ
08:12-!-peter1138 [~petern@176-35-84-218.xdsl.murphx.net] has quit [Ping timeout: 480 seconds]
08:17-!-petern is now known as peter1138
08:21-!-Rhamphoryncus [~rhamph@d161-184-227-133.abhsia.telus.net] has quit [Quit: Rhamphoryncus]
08:24-!-roboboy [~robotboy@CPE-58-173-43-55.nxzp1.ken.bigpond.net.au] has joined #openttd
08:26-!-Pikka [~chatzilla@d58-111-69-99.rdl800.qld.optusnet.com.au] has quit [Quit: ChatZilla 0.9.88.2 [Firefox 11.0/20120312181643]]
08:30-!-Sludge321 [~matt@124-169-217-191.dyn.iinet.net.au] has left #openttd []
08:47-!-DanMacK [~Cyclone29@CPE602ad091690d-CM602ad091690a.cpe.net.cable.rogers.com] has joined #openttd
08:49-!-glx [glx@2a01:e35:2f59:c7c0:3046:2b93:3f65:51db] has joined #openttd
08:49-!-mode/#openttd [+v glx] by ChanServ
08:57-!-DanMacK [~Cyclone29@CPE602ad091690d-CM602ad091690a.cpe.net.cable.rogers.com] has quit []
08:59-!-roboboy [~robotboy@CPE-58-173-43-55.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds]
09:11-!-Kul [~opera@D97BF121.cm-3-4d.dynamic.ziggo.nl] has joined #openttd
09:12-!-Kul [~opera@D97BF121.cm-3-4d.dynamic.ziggo.nl] has left #openttd []
09:17-!-cypher [~Miranda@ip-89-176-205-158.net.upcbroadband.cz] has joined #openttd
09:24<@Belugas>hello
09:24<drac_boy>hi
09:32-!-drac_boy [~drac_boy@bas1-ottawa08-1177643171.dsl.bell.ca] has left #openttd [I'm done being in this room!]
09:34-!-oskari89 [~oskari89@213-186-253-165.bb.dnainternet.fi] has joined #openttd
09:37-!-glx is now known as Guest926
09:37-!-glx_ [glx@2a01:e35:2f59:c7c0:3046:2b93:3f65:51db] has joined #openttd
09:37-!-mode/#openttd [+v glx_] by ChanServ
09:37-!-glx_ is now known as glx
09:43-!-Guest926 [glx@2a01:e35:2f59:c7c0:3046:2b93:3f65:51db] has quit [Ping timeout: 480 seconds]
10:06-!-TWerkhoven [~twerkhove@cpc3-linl7-2-0-cust522.sgyl.cable.virginmedia.com] has joined #openttd
10:19-!-cypher [~Miranda@ip-89-176-205-158.net.upcbroadband.cz] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
10:31-!-peter1138 [~petern@petern.bnsnet.co.uk] has quit [Read error: No route to host]
10:31-!-petern [~petern@petern.bnsnet.co.uk] has joined #openttd
10:31-!-mode/#openttd [+o petern] by ChanServ
10:46-!-Jupix2 [~jupix@dsl-lprbrasgw1-ff11c100-110.dhcp.inet.fi] has joined #openttd
10:46-!-roadt__ [~roadt@60.168.94.103] has quit [Ping timeout: 480 seconds]
10:46-!-andythenorth [~Andy@cpc23-aztw25-2-0-cust33.aztw.cable.virginmedia.com] has joined #openttd
10:46-!-supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has joined #openttd
10:47-!-zxbiohazardzx [~IceChat77@5ED05D6D.cm-7-1b.dynamic.ziggo.nl] has joined #openttd
10:48-!-zxbiohazardzx [~IceChat77@5ED05D6D.cm-7-1b.dynamic.ziggo.nl] has left #openttd []
10:49-!-goodger [~ben@94-30-43-248.xdsl.murphx.net] has joined #openttd
10:50-!-Jupix [~jupix@88.193.17.110] has quit [Ping timeout: 480 seconds]
10:55-!-roadt__ [~roadt@60.168.94.103] has joined #openttd
10:57-!-oskari89 [~oskari89@213-186-253-165.bb.dnainternet.fi] has quit []
11:11-!-LordPixaII [~pixa@85.210.69.185] has joined #openttd
11:12-!-flaa [~flaa@089-101-093077.ntlworld.ie] has joined #openttd
11:12-!-TWerkhoven [~twerkhove@cpc3-linl7-2-0-cust522.sgyl.cable.virginmedia.com] has quit [Quit: He who can look into the future, has a brighter future to look into]
11:16-!-HerzogDeXtEr [~Flex@i59F6D81.versanet.de] has joined #openttd
11:17-!-Pixa [~pixa@85.210.73.85] has quit [Ping timeout: 480 seconds]
11:26-!-Prof_Frink [~proffrink@5e09ee84.bb.sky.com] has joined #openttd
11:57-!-tokai|mdlx [~tokai@port-92-195-102-231.dynamic.qsc.de] has joined #openttd
12:01<@planetmaker>http://www.hwaci.com/cgi-bin/license-step1 <-- I guess we should offer this service, too
12:02-!-kaenkky [~kaenkky_@212-226-74-9-nat.elisa-mobile.fi] has quit [Quit: d]
12:03-!-tokai|noir [~tokai@port-92-195-119-137.dynamic.qsc.de] has quit [Ping timeout: 480 seconds]
12:04-!-Progman [~progman@p57A1AABE.dip.t-dialin.net] has joined #openttd
12:08<andythenorth>offer custom consulting on the codebase too ;)
12:08-!-Xaroth_ [~Xaroth@059-057-128-083.dynamic.caiway.nl] has quit [Ping timeout: 480 seconds]
12:11<@planetmaker>yep. DaleStan set good example on the hourly rates ;-)
12:33-!-kaenkky [~kaenkky_@212-226-74-9-nat.elisa-mobile.fi] has joined #openttd
12:48-!-supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has quit [Quit: supermop]
12:52<@Terkhen>hello
12:54-!-andythenorth [~Andy@cpc23-aztw25-2-0-cust33.aztw.cable.virginmedia.com] has quit [Quit: andythenorth]
12:55<krinn>hi Terkhen
12:55<krinn>anyone could explain the new destination too far on aircrafts ?
12:56<krinn>it was working fine before, now i see that in orders
12:56<@planetmaker>krinn, aircraft can now have a maximum range
12:56<@planetmaker>Thus you cannot send it necessarily to every airport
12:56<krinn>per vehicle type range or a global limit ?
12:57<@planetmaker>Also orders like A->B->C may fail, if C->A is too far
12:57<@planetmaker>it's a per-vehicle type limit
12:57<@planetmaker>NewGRF-defined
12:57<krinn>hell
12:57<@planetmaker>default it doesn't exist
12:57<krinn>why A->B->C fail because a->c too far? the aircraft will do ab then bc no ?
12:58<@planetmaker>Not sure what it does, if A->B and B->C is valid
12:58-!-andythenorth [~Andy@cpc23-aztw25-2-0-cust33.aztw.cable.virginmedia.com] has joined #openttd
12:58<krinn><planetmaker> default it doesn't exist : it's an new option in config ?
12:59<@planetmaker>no
12:59<@planetmaker>It's a NewGRF property
12:59<@planetmaker>Either the NewGRF defines it. Or it doesn't
12:59<krinn>ah ok, so it's no openttd that bug me, just another newGRF so :)
12:59<@planetmaker>probably only av8 :-)
12:59<@planetmaker>I know no other which uses it ;-)
13:00<@planetmaker>but an AI would want to support it
13:00<krinn>that fucking newGRF is a hell for AI
13:00<krinn>always something with it!
13:00<@planetmaker>lol
13:01<@planetmaker>no-one said it was easy ;-)
13:01<krinn>specially this one !
13:02<@planetmaker>what makes it hard?
13:02-!-Xaroth [~Xaroth@059-057-128-083.dynamic.caiway.nl] has joined #openttd
13:02<krinn>well, nothing, just that now my AI pickup aircraft that are stuck at depot
13:04<@planetmaker>http://noai.openttd.org/api/trunk/classAIEngine.html#a0d3c115704bfc200432f4908df8b6ff and http://noai.openttd.org/api/trunk/classAIOrder.html#e25118472500d3e2ca33512aec378dc7 should do the trick
13:04<@planetmaker>The same way that OpenTTD eveloves, NewGRF evolve. And of course AIs then have to evolve, too...
13:05<@planetmaker>And the API needs a new 1.2.0 link :-)
13:05<@planetmaker>the API docs
13:05<krinn>yeah, but i just see the close point there
13:05<krinn>checking airport->airport tile ok but then airport->depot tile of other airport just 1 tile too far = dead
13:06<krinn>how great! now we will need all depot vs depot vs airport vs airport... combo
13:06<@planetmaker>check distance of airports
13:06<krinn>yep, but i must enable a per route aircraft type handling
13:08<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
13:08<@planetmaker>Probably all AIs
13:08<krinn>lol i love your "probably"
13:09<@planetmaker>Road-only AIs will not fail
13:09<@planetmaker>nor ship-only
13:09<krinn>until road newGRF put distance limit too
13:09<@planetmaker>that won't happen ;-)
13:09<@planetmaker>at least I see no reason to add such limit. While it makes sense for air
13:10<andythenorth>^^ same issues will occur with NoGo
13:10<andythenorth>[just saying]
13:10<@planetmaker>Every add-on will face sometimes a situation where interaction with another add-on will change things it takes for granted
13:10<@planetmaker>and that's exactly what happens here
13:10<andythenorth>is there ever any promise between AI and NewGRFs?
13:11<@planetmaker>There's no promise
13:11-!-Chris_Booth [~chatzilla@host81-129-125-202.range81-129.btcentralplus.com] has joined #openttd
13:11<andythenorth>so this is 'correct'
13:11<andythenorth>rather than 'wrong'
13:11<krinn>the real problem is newGRF take over AI
13:11<@planetmaker>AIs are only promised a "best effort" to make available all neccessary info via the API
13:11<@planetmaker>krinn, they don't
13:11<@planetmaker>The newgrf just implements something not available in earlier versions
13:12<@planetmaker>something the AI cannot know or have known before, true
13:12<krinn>well i can't make an AI that wreck a newGRF even with newer API
13:12<@planetmaker>But it's by no means a take over
13:12<@planetmaker>of course not. But that's for the definition of the two:
13:12<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
13:12<@planetmaker>NewGRF = game ressources
13:12<@planetmaker>AI = player
13:13<@planetmaker>so the player can never break the game. While the game can break with new rules and behaviour established playing style
13:13<@planetmaker>That's not surprising and nothing which even can nor should be changed
13:13<@planetmaker>NewGRFs' purpose is to change the way the game works
13:13<krinn>any players (ok maybe not all) can bypass this easy, for an AI, need a rewrite
13:14<andythenorth>it's a "nothing to see here" kind of issue
13:14<andythenorth>filed under "some problems can't be solved"
13:14<@planetmaker>krinn, players cannot bypass that at all ;-) They can, similar to an AI, just choose to not play ;-)
13:15<krinn>as of today, that newGRF will broke any AI using aircraft, that's just a fact
13:15<@planetmaker>yes
13:15<krinn>a player will just dismiss the aircraft, until he have no other choice and remove the newGRF if this bug him too much
13:15<@planetmaker>That's why AIs declare an API version to be compatible with
13:15<@planetmaker>though that won't help here, either
13:15<krinn>the AI cannot remove it
13:16<@planetmaker>yes, the AI could choose to ignore aircraft if it finds that the established methods don't work
13:16<@planetmaker>thus do the same a player does
13:16<krinn>yes, but AI isn't adaptive to new event like that, like a human do
13:16<@planetmaker>this of course needs some meta knowledge analysing existing vehicles and stuff
13:17<krinn>hence the AI rewrite to adapt it, not that easy
13:17<@planetmaker>yup. That's how it is
13:17<@planetmaker>Write it as a module or small library and all AI could profit ;-)
13:17<krinn>and we never get benefits from newGRF nearly :(
13:17-!-frosch123 [~frosch@frnk-590d513c.pool.mediaWays.net] has joined #openttd
13:18<krinn>i cannot query and set another livery/color for an engine per example
13:18<@planetmaker>what do you mean with "benefit"?
13:18<andythenorth>AI is not afaict really considered when discussing newgrf specs
13:18<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
13:18<andythenorth>if AI also had to accounted for, newgrf would basically go int stasis
13:18<andythenorth>into /s
13:19<krinn>i can't remember the name, but a newgrf for train provide diff spd/power of an engine you could switch too
13:19<andythenorth>NARS 2
13:19<krinn>something "benefits" for any players
13:19<krinn>AI, no way
13:19<@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"
13:20<krinn>well, it could save a lot of AI, if something like this one happen again
13:20<@planetmaker>anyway, krinn, you're only doing destructive criticism.
13:20<@planetmaker>Constructive comments would be well more welcome
13:20<andythenorth>AI authors need to maintain their stuff
13:20<krinn>what do you expect ? i'm french, we're master at criticism
13:20<andythenorth>as DaleStan once said
13:21<andythenorth>"It behooves you to keep up to date in a fast-moving language"
13:21<andythenorth>or so
13:21<@planetmaker>I expect constructive comments which help your situtations
13:21<@planetmaker>other than "NewGRFs suck, they may break my AIs"
13:21<@planetmaker>That's not going anywhere
13:21<@planetmaker>Nor is "NewGRFs must not implement new game-changing features" a solution
13:21<krinn>saddly there's not, you took care already to provide needed stuff in the API so we could cry but not yell :)
13:21<andythenorth>planetmaker: we *could* insist on backwards compatibility, same as for newgrf spec
13:21<andythenorth>"you may not break existing AIs" ?
13:22<@planetmaker>andythenorth, but that means to not change the game rules
13:22<@planetmaker>which defies the purpose of new NewGRF features
13:22<andythenorth>I said we could
13:22<andythenorth>not that it's good
13:22<andythenorth>:)
13:22<@planetmaker>same with new game script capabilities actually
13:22-!-Sacro [~ben@150.237.48.99] has quit [Ping timeout: 480 seconds]
13:22<krinn>at least, a little message in AI forum would have been nice to tell AI author about the new failure
13:23<@planetmaker>which might even pose a bigger challange actually for current AIs. No idea
13:23<@planetmaker>krinn, then please go ahead. No-one thought of that so far, I guess
13:23<krinn>or no one see it yet no ?
13:23<krinn>i have just discover it today
13:24<@planetmaker>not that I know. Not that it may mean that no-one noticed
13:24<@planetmaker>But not sure
13:25<@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.
13:26<@planetmaker>Whatever that may actually be. Finding issues. Reporting issues. Notifying AI authors, writing AI API patches to add things needed,...
13:26<@planetmaker>and of course writing and improving AIs
13:26<krinn>i know, i know, i couldn't help myself, else i would
13:26<krinn>but sometimes it looks like newGRF goes too fast vs AI
13:26<andythenorth>ha ha
13:26<andythenorth>high contrast graphics ftw
13:26<krinn>i'm still waiting a way to manage to remove a wagon from a train to place it on another one :/
13:27<@planetmaker>like players: separate it. Then add it to new train
13:27<andythenorth>think of all the edge cases to handle there :o
13:27<krinn>ehehe, except we can't click, once sperate the wagon ID is lost
13:27<andythenorth>'this train needs a brake van'
13:27<andythenorth>'this wagon can only be attached to train xyz'
13:28<andythenorth>'this train cannot have more than n wagons'
13:28<andythenorth>:o
13:28<andythenorth>it's a tough life for AI authors :)
13:28-!-zooks [~zooks@vhe-540241.sshn.net] has joined #openttd
13:28<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
13:29<andythenorth>have you tried 'worse is better' ? :)
13:29<krinn>lol i'm scare already this name would be attach to a newGRF
13:29<andythenorth>http://dreamsongs.com/WorseIsBetter.html
13:29<andythenorth>and http://dreamsongs.com/RiseOfWorseIsBetter.html
13:30<andythenorth>specifically the example of how UNIX won by handling failures more bluntly
13:30<andythenorth>dunno how it relates here, but it seems to
13:31<andythenorth>planetmaker: fancy adding any FIRS translations? Think there are updates....
13:32<@planetmaker>I might do later today
13:33<krinn>planetmaker : that one from MoveWagon -> dest_vehicle_id The vehicle to move the wagon to, or -1 to create a new vehicle.
13:33<krinn>until MoveWagon return the new ID, we're dead at switching engine/wagon from one train to another one
13:34<krinn>and wagons remain lost in depot
13:34<krinn>can't even erase them :/
13:34<@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
13:34<@planetmaker>But train building surely needs test building
13:35<@planetmaker>It also means that for me myself
13:35<@planetmaker>reading readme is for wimps ;-)
13:35<krinn>:)
13:35-!-andythenorth [~Andy@cpc23-aztw25-2-0-cust33.aztw.cable.virginmedia.com] has quit [Quit: andythenorth]
13:35<@planetmaker>except of course readme, section 4, line 191 ff
13:35<@planetmaker>:-P
13:35<@planetmaker>but I know that by heart
13:36<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
13:36<@planetmaker>but you surely can check which vehicles are in the depot?
13:37<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
13:38<krinn>except of course, sometimes the dummy wagon fail because of the "cannot attach..." :P
13:39<krinn>told you planetmaker newGRF authors put all their efforts at bugging AI authors :)
13:39<@planetmaker>of course. Where would otherwise be the fun?
13:39<krinn>^^
13:40-!-andythenorth [~Andy@cpc23-aztw25-2-0-cust33.aztw.cable.virginmedia.com] has joined #openttd
13:41<@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
13:42<andythenorth>it's bound to be in the last place you look ;)
13:42<krinn>sed is your friend
13:43<@planetmaker>krinn, that doesn't help me to actually find the cause... once I knew, of course
13:43<@planetmaker>the bad thing was that the fig(ure) shows the fit :-P
13:43<@planetmaker>bad bad typo
13:45<CIA-1>OpenTTD: translators * r24154 /trunk/src/lang/ (7 files): (log message trimmed)
13:45<CIA-1>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-1>OpenTTD: afrikaans - 53 changes by telanus
13:45<CIA-1>OpenTTD: danish - 10 changes by mgarde
13:45<CIA-1>OpenTTD: finnish - 12 changes by jpx_
13:45<CIA-1>OpenTTD: lithuanian - 11 changes by Stabilitronas
13:45<CIA-1>OpenTTD: brazilian_portuguese - 12 changes by Tucalipe
13:46-!-zooks [~zooks@vhe-540241.sshn.net] has quit [Ping timeout: 480 seconds]
13:47-!-mal2 [~mal2@port-92-206-197-67.dynamic.qsc.de] has joined #openttd
13:48<andythenorth>planetmaker: I'm looking at http://dev.openttdcoop.org/issues/1564
13:49<andythenorth>I'm testing with 256x256 mountainous, rough, high sea
13:49<andythenorth>- all the larger industries have issues occasionally
13:49<andythenorth>- but the only pathological cases are quarry / clay pit - missing on every map so far
13:51<Nat_aS>can you make an industry that can ONLY be placed on slopes?
13:51<Nat_aS>because it would be cool if there was a quarry that was built into a hillside
13:53-!-frosch123 [~frosch@frnk-590d513c.pool.mediaWays.net] has quit [Remote host closed the connection]
13:53<andythenorth>Nat_aS: yes, but it's too hard to place, so the game would rarely build it
13:53<andythenorth>Pikka has it in PBI
13:54<V453000>yeah there is always only a few on the map
13:55<andythenorth>hmm
13:55<andythenorth>come back frosch :P
13:56<andythenorth>if industry was moved to 'something like NoGo', then the problem could be solved
13:57<Nat_aS>well the idea is it would be an alternative sprite.
13:57<Nat_aS>if there are no hillsides, it builds the flat version, if there are no flat spaces, it builds the hillside version
13:57-!-telanus1 [~Barney_Er@196.215.173.27] has joined #openttd
13:58<andythenorth>Nat_aS: you just get the flat one a lot :P
13:58<andythenorth>or none
13:58<@planetmaker>andythenorth, invent a (much) smaller layout for them or one which fits slopes :-)
13:58<andythenorth>the chances of finding exactly the right hillside is....low
13:58<andythenorth>planetmaker: I'm thinking smaller layout
13:58<@planetmaker>yes.
13:58<andythenorth>or break it into two components
13:58<@planetmaker>both. hillside + smaller
13:58<andythenorth>hillside I've been avoiding for ages :P
13:58<@planetmaker>It's not like that we can easily add a dozen layouts, if it's modular enough
13:59<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.
13:59<andythenorth>modular is the problem
13:59<andythenorth>a sloped 3x3 quarry means drawing 9 tiles
13:59<Nat_aS>not with flat areas on both sides.
13:59<andythenorth>@calc 9*16
13:59<@DorpsGek>andythenorth: 144
13:59<andythenorth>but the combinations of different slopes means drawing at least 144 tiles iirc
13:59<andythenorth>not happening
13:59<andythenorth>george has done it for ECS though :P
14:00<andythenorth>and it looks nice in ECS
14:00<@planetmaker>quite
14:00<@planetmaker>but why does it need 144 tiles?
14:00<andythenorth>all the different slope combinations
14:00<andythenorth>might be less
14:00<andythenorth>I worked it out properly once
14:00<@planetmaker>there are 19 slopes
14:00<andythenorth>might be more then :P
14:01<andythenorth>suffice to say, it was lots
14:01<@planetmaker>@calc 19 * 5 + 19*4
14:01<@DorpsGek>planetmaker: 171
14:01<andythenorth>although restricting to just, say \ view
14:01<andythenorth>makes it easier
14:01<@planetmaker>:-P
14:01<andythenorth>there's no point building on slopes on N side of map
14:01<@planetmaker>if you really want arbitrary placement, then it's 171
14:01<@planetmaker>why?
14:01-!-Alberth [~hat3@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
14:01-!-mode/#openttd [+o Alberth] by ChanServ
14:01<andythenorth>I mean the rear face of a hill
14:02<andythenorth>you won't see much :P
14:02<@planetmaker>why?
14:02<andythenorth>maybe that's the *best* place to build them
14:02<@planetmaker>easy to draw
14:02<andythenorth>ho
14:02-!-telanus [~Barney_Er@196.215.173.27] has quit [Ping timeout: 480 seconds]
14:02<@Alberth>hu all
14:02<Nat_aS>honestly though, I want to see more scenerios that use industry grfs
14:02<@planetmaker>hullo Alberth
14:02<andythenorth>actually, the angle isn't so acute as I though
14:02<andythenorth>t
14:02<andythenorth>you would see most of the quarry
14:02<andythenorth>hi Alberth
14:02<Nat_aS>and hate random maps
14:03<Nat_aS>so placing industries randomly is not something i care about :P
14:03<@planetmaker>Nat_aS, go right ahead and create them ;-)
14:03<@Alberth>andythenorth: you are painting for the wrong game :p
14:03<@planetmaker>not at all
14:03<andythenorth>Alberth: would you prefer one with coasters?
14:03<@Alberth>RCT goes down at the back without showing any surface
14:04<Nat_aS>I do however need good heightmaps though :P
14:04<andythenorth>surely something 'like NoGo' (as discussed yesterday) would also enable terraforming on industry construction?
14:05<andythenorth>basically, industry grf helper scripts
14:05<@Alberth>newgrf should give hints
14:05<andythenorth>bundle a script in the tar with the newgrf
14:05<@Alberth>then I am sure openttd can manage without (no)go script
14:05<andythenorth>have it handle the calls from the game
14:05-!-Chris_Booth [~chatzilla@host81-129-125-202.range81-129.btcentralplus.com] has quit [Ping timeout: 480 seconds]
14:06-!-Chris_Booth [~chatzilla@host81-129-125-202.range81-129.btcentralplus.com] has joined #openttd
14:06<@Alberth>or do you want the nogo script to perform terra forming?
14:06<andythenorth>yes
14:07<krinn>i love sed ! find . -name "*.nut" -print | xargs sed -i 's/AIOF_/OF_/g'
14:07<@Alberth>sounds like the wrong place to me, tbh
14:07<andythenorth>it was a suggestion yesterday
14:07<andythenorth>would also handle closures better....maybe
14:07<andythenorth>maybe not actually
14:08<@planetmaker>wasn't the suggestion rather: create a mapgen API? :-)
14:09<andythenorth>was it? :)
14:09<andythenorth>hmm
14:09<andythenorth>currently the clay pit / quarry require all tiles to be absolutely flat
14:10<andythenorth>because foundations at the edges of it look stupid
14:10<andythenorth>maybe it should use 2 tiles
14:10<andythenorth>the centre tiles could be on slopes
14:11<andythenorth>maybe not
14:12-!-Alberth1 [~hat3@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
14:12-!-mode/#openttd [+o Alberth1] by ChanServ
14:12-!-Alberth [~hat3@a82-95-164-127.adsl.xs4all.nl] has quit [Quit: Leaving.]
14:12-!-Alberth1 is now known as Alberth
14:13<@Alberth>lol, SElinux killed the network manager for accessing a file, and it took down the connection as well :)
14:14-!-Chris_Booth [~chatzilla@host81-129-125-202.range81-129.btcentralplus.com] has quit [Remote host closed the connection]
14:17-!-KouDy [~KouDy@175.137.102.249] has quit [Quit: Leaving.]
14:18<andythenorth>so...hints from newgrf to terraforming?
14:21<@Alberth>wouldn't that be better?
14:23-!-Wolf01 [~wolf01@host139-62-dynamic.252-95-r.retail.telecomitalia.it] has joined #openttd
14:24<Wolf01>helloink
14:24<andythenorth>Alberth: maybe
14:24<@Alberth>oi Wolf01
14:24<andythenorth>I should try and figure out if it solves the case
14:24<Nat_aS>hey, when was the ability to join stations with the ctrl key removed?
14:24<@Alberth>Nat_aS: nope
14:24<andythenorth>the problem is placing industries that need a large flat area
14:25<@Alberth>but it won't work if the stations are too far away
14:25<Nat_aS>oh it's an option
14:25<Nat_aS>was it always an option, or did that change?
14:25<@Alberth>no change recently there Nat_aS
14:26-!-petern [~petern@petern.bnsnet.co.uk] has quit [Quit: Ex-Chat]
14:27<@Alberth>andythenorth: that's an extreme case, so you'd expect to get trouble in such cases
14:32<andythenorth>Alberth: in that case the work of adding hints is probably tmwftlb
14:32<andythenorth>it wouldn't be simple
14:32<andythenorth>lots of varact 2 needed for them
14:33<andythenorth>the issue is better solved by 'make smaller industries'
14:34<@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
14:35<andythenorth>I can't think of another :)
14:35<andythenorth>it's all we have
14:35<andythenorth>unless the industry layout def is extended in action 0
14:42-!-Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has joined #openttd
14:47<andythenorth>bah
14:47<andythenorth>http://www.tt-forums.net/viewtopic.php?p=1009347#p1009347
14:47<andythenorth>new bug :|
14:47*andythenorth has to go to the pub though
14:47-!-DDR [~chatzilla@d99-199-14-2.bchsia.telus.net] has joined #openttd
14:48<andythenorth>bye
14:48-!-andythenorth [~Andy@cpc23-aztw25-2-0-cust33.aztw.cable.virginmedia.com] has quit [Quit: andythenorth]
14:48-!-DDR [~chatzilla@d99-199-14-2.bchsia.telus.net] has quit []
14:48-!-DDR [~chatzilla@d99-199-14-2.bchsia.telus.net] has joined #openttd
14:53-!-fonsinchen [~fonsinche@dslb-178-000-005-077.pools.arcor-ip.net] has joined #openttd
15:00-!-ffpp [~me@dslb-188-107-137-123.pools.arcor-ip.net] has joined #openttd
15:01<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
15:02<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 ?
15:02<Rubidium>they're the same
15:03<ffpp>hm, the diagram in the game looks way less harsh than the formula in the wiki sounds
15:03<ffpp>or can this be altered by newgrfs ?
15:04<Rubidium>looks are deceiving, and yes
15:12-!-Zeknurn [~Zeknurn@hd9483b0c.seveveb.dyn.perspektivbredband.net] has quit [Remote host closed the connection]
15:12<Rubidium>also the graph in OpenTTD shows about 30% of the cargo payment range
15:12-!-Zeknurn [~Zeknurn@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd
15:13<Rubidium>and that alone will significantly distort what you see
15:16<ffpp>i know, the scale can distort the look of a graph
15:17<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
15:17<ffpp>but the cargo payment rate graph shows a drop-off in ~50% for passengers over the span of 200 days
15:17<ffpp>that's why I was wondering if there is a difference
15:19<Rubidium>the maximum penalty applies after 255 'days'. I say 'days' because a 'day' for the cargo payment is actually 2.5 game days
15:19<Rubidium>as described in the cargo income page on the wiki
15:20<Rubidium>so the maximum penalty applies after about 637 days
15:21<Rubidium>hmm, although... the slope's ofcourse different
15:23<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
15:26<Rubidium>if my math is right, the lowest payment is after 124*2.5 days = 310 game days
15:27<Rubidium>likewise after 200 days you'd be at 47% of maximum payment
15:28<ffpp>sounds fitting
15:36-!-Rhamphoryncus [~rhamph@d161-184-227-133.abhsia.telus.net] has joined #openttd
15:39-!-ffpp [~me@dslb-188-107-137-123.pools.arcor-ip.net] has quit [Quit: ffpp]
15:41-!-Sacro [~ben@150.237.48.99] has joined #openttd
15:43-!-fip [~fip@5356EAD1.cm-6-7d.dynamic.ziggo.nl] has joined #openttd
15:47-!-Alberth [~hat3@a82-95-164-127.adsl.xs4all.nl] has left #openttd []
15:51<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 _settings_client.music.music_vol 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
15:51<fip>ug and is there a fix?
15:53<Rubidium>it does start when the main menu is shown?
15:53<Rubidium>i.e. after the NewGRF/content scan
15:54-!-drac_boy [~drac_boy@bas1-ottawa08-1177643171.dsl.bell.ca] has joined #openttd
15:54<drac_boy>hi
15:56<fip>no, it doesn't start until the volume control in the music window is touched
15:58<Rubidium>then http://rbijker.net/openttd/foes.diff will probably fix it, right?
16:01<fip>thank's a lot: that looks very promising!
16:04<fip>yup: success! :-)
16:06-!-peteris [~peteris@78.84.100.24] has joined #openttd
16:08*Rhamphoryncus accidentally sends his entire fleet for servicing x_x
16:08<Rubidium>turn the undo knob!
16:08<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
16:13<Rhamphoryncus>And even when I cancel the servicing they're already down the wrong path, so the depot is the "best" place to reverse
16:15<drac_boy>heh
16:16-!-Biolunar [~mahdi@blfd-5d8208e5.pool.mediaWays.net] has joined #openttd
16:20-!-frosch123 [~frosch@frnk-590d513c.pool.mediaWays.net] has joined #openttd
16:21-!-telanus1 [~Barney_Er@196.215.173.27] has left #openttd []
16:30-!-bobfred [516bcafb@ircip2.mibbit.com] has joined #openttd
16:31-!-bobfred [516bcafb@ircip2.mibbit.com] has quit []
16:32-!-peter1138 [~petern@84.246.159.210] has joined #openttd
16:33-!-Chris_Booth [~chatzilla@host81-129-125-202.range81-129.btcentralplus.com] has joined #openttd
16:34-!-Progman [~progman@p57A1AABE.dip.t-dialin.net] has quit [Remote host closed the connection]
16:43-!-Miguelzinho [~Miguelzin@201.77.177.82] has quit [Quit: Leaving]
16:47<Zuu>@ports
16:47<@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)
16:56<@Terkhen>good night
17:00-!-fip [~fip@5356EAD1.cm-6-7d.dynamic.ziggo.nl] has left #openttd []
17:03-!-KritiK [~Maxim@95-25-205-242.broadband.corbina.ru] has joined #openttd
17:04-!-TWerkhoven[l] [~twerkhove@cpc3-linl7-2-0-cust522.sgyl.cable.virginmedia.com] has quit [Ping timeout: 480 seconds]
17:10-!-Chris_Booth [~chatzilla@host81-129-125-202.range81-129.btcentralplus.com] has quit [Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120411064248]]
17:13-!-Firartix [~artixds@222.140.0.93.rev.sfr.net] has quit [Ping timeout: 480 seconds]
17:18-!-MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has joined #openttd
17:18-!-frosch123 [~frosch@frnk-590d513c.pool.mediaWays.net] has quit [Remote host closed the connection]
17:20-!-fonsinchen [~fonsinche@dslb-178-000-005-077.pools.arcor-ip.net] has quit [Remote host closed the connection]
17:28-!-peteris [~peteris@78.84.100.24] has quit [Quit: Ex-Chat]
17:29-!-Elukka [Elukka@78-27-90-14.bb.dnainternet.fi] has quit []
17:41-!-TGYoshi [~TGYoshi@86.81.146.146] has quit [Quit: Popidopidopido]
17:45-!-goodger [~ben@94-30-43-248.xdsl.murphx.net] has quit [Ping timeout: 480 seconds]
17:47-!-flaa [~flaa@089-101-093077.ntlworld.ie] has quit [Quit: leaving]
17:57-!-FLHerne [~francis_h@dsl-217-155-24-22.zen.co.uk] has left #openttd []
18:04-!-drac_boy [~drac_boy@bas1-ottawa08-1177643171.dsl.bell.ca] has left #openttd [I'm done being in this room!]
18:22-!-cypher [~Miranda@ip-89-176-205-158.net.upcbroadband.cz] has joined #openttd
18:24-!-morten [~morten@ti0008a380-dhcp2946.bb.online.no] has joined #openttd
18:25<morten>hi, is there enyone here?
18:26<morten>i was wondering if there was someone who could help me install a server on my debian squezze server.
18:26<morten>thanks
18:33<peter1138>install it
18:33<peter1138>run it
18:45-!-sla_ro|master [slaco@95.76.26.172] has quit [Quit: DANGER sla.ro is OFFLINE DANGER]
18:45<morten>from where
18:45<morten>trying to type: openttd -D
18:45<morten>it doesen't exist
18:46<morten>where do the file get installed?
18:46<Eddi|zuHause>how did you "install" it?
18:48<morten>dpkg -i
18:49<morten>openttd-1.2.0-linux-debian-squeeze-i386.deb
18:50<Wolf01>'night
18:50-!-Wolf01 [~wolf01@host139-62-dynamic.252-95-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.]
18:53<morten>or do i have to have a server with a graphical gui
18:56<Eddi|zuHause>your package manager then should have a way to tell you where the files ended up
18:56<Eddi|zuHause>then you need to check whether that place is in your path
18:58<krinn>if openttd is install-> whereis openttd and you'll get your answer
19:00<morten>thanks, sry for being noob :P gotta learn somehow, hehe
19:01<+glx>if you want a build without GUI dependancy you need to compile it yourself
19:02<morten>thought something like that now, it asked me for video driver
19:02<morten>or, it says that it can't find graphic set
19:02<+glx>graphic set is always required
19:03<morten>http://wiki.openttd.org/Compiling_on_Linux#Running, can i use something from this site?
19:11<heffer>i was always wondering if i can build a gui and non-gui version of openttd in one go?
19:12<heffer>might be interesting for packaging
19:14<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
19:17<morten>think this script could do. But again, im not any good. http://openttd.btpro.nl/index.php/forum/24-experienced-coders-wanted-c/540-script-to-compile-openttd115-server-from-source
19:19<morten>good night, thanks for the help i have gotten
19:20-!-morten [~morten@ti0008a380-dhcp2946.bb.online.no] has quit [Quit: Lost terminal]
19:22-!-brambles [brambles@79.133.200.49] has quit [Ping timeout: 480 seconds]
19:26-!-brambles [brambles@79.133.200.49] has joined #openttd
19:28-!-KritiK [~Maxim@95-25-205-242.broadband.corbina.ru] has quit [Quit: Leaving]
19:30-!-LordPixaII [~pixa@85.210.69.185] has quit [Ping timeout: 480 seconds]
19:32-!-Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds]
19:52-!-roadt__ [~roadt@60.168.94.103] has quit [Ping timeout: 480 seconds]
19:54-!-mahmoud [~KEM@ALyon-158-1-89-240.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
19:58-!-mal2 [~mal2@port-92-206-197-67.dynamic.qsc.de] has quit [Ping timeout: 480 seconds]
20:01<Ammler>heffer: I do that for suse
20:03<Ammler>https://build.opensuse.org/package/view_file?file=openttd.spec&package=openttd&project=games
20:09<Mazur>morten: Have you looked at /usr/local/bin ?
20:09<Mazur>Oh, he;s already gone.
20:19-!-Biolunar [~mahdi@blfd-5d8208e5.pool.mediaWays.net] has quit [Read error: Connection reset by peer]
20:19-!-Biolunar [~mahdi@blfd-5d8208e5.pool.mediaWays.net] has joined #openttd
20:21-!-cypher [~Miranda@ip-89-176-205-158.net.upcbroadband.cz] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
20:22-!-Mek_ [~quassel@marijnalexwedding.com] has joined #openttd
20:25-!-Mek [~quassel@marijnalexwedding.com] has quit [Read error: Connection reset by peer]
20:26-!-Djohaal [~Djohaal@189.114.232.248.dynamic.adsl.gvt.net.br] has joined #openttd
20:28-!-Mek_ is now known as Mek
20:44-!-XeryusTC [~XeryusTC@101.haydn.openttdcoop.org] has quit [Ping timeout: 480 seconds]
20:44-!-planetmaker [~planetmak@101.haydn.openttdcoop.org] has quit [Ping timeout: 480 seconds]
20:44-!-Ammler [~ammler@101.haydn.openttdcoop.org] has quit [Ping timeout: 480 seconds]
20:45-!-xQR [xor@the.x-base.org] has quit [Ping timeout: 480 seconds]
20:45-!-xQR [xor@the.x-base.org] has joined #openttd
20:46-!-Ammler [~ammler@101.haydn.openttdcoop.org] has joined #openttd
20:47-!-XeryusTC [~XeryusTC@101.haydn.openttdcoop.org] has joined #openttd
20:47-!-planetmaker [~planetmak@178.63.83.101] has joined #openttd
20:48-!-planetmaker is now known as Guest1005
20:53-!-Biolunar [~mahdi@blfd-5d8208e5.pool.mediaWays.net] has quit [Quit: All your IRC are belong to us]
21:01-!-bb10X [~bb10@bb10x.org] has quit [Ping timeout: 480 seconds]
21:03-!-bb10 [~bb10@bb10x.org] has joined #openttd
21:07-!-Stimrol_ [~Stimrol@dsl-149-87-36.hive.is] has quit [Quit: ZNC - http://znc.sourceforge.net]
21:07-!-HerzogDeXtEr [~Flex@i59F6D81.versanet.de] has quit [Read error: Connection reset by peer]
21:08-!-Stimrol [~Stimrol@dsl-149-87-36.hive.is] has joined #openttd
21:11-!-HerzogDeXtEr [~Flex@i59F6D81.versanet.de] has joined #openttd
21:15-!-pugi [~pugi@host-091-097-069-005.ewe-ip-backbone.de] has quit []
21:30-!-HerzogDeXtEr1 [~Flex@i59F6D81.versanet.de] has joined #openttd
21:34-!-HerzogDeXtEr [~Flex@i59F6D81.versanet.de] has quit [Read error: Connection reset by peer]
21:42-!-brambles [brambles@79.133.200.49] has quit [Quit: leaving]
21:43-!-brambles [brambles@79.133.200.49] has joined #openttd
21:48-!-Djohaal [~Djohaal@189.114.232.248.dynamic.adsl.gvt.net.br] has quit [Quit: Leaving]
22:00-!-HerzogDeXtEr [~Flex@i59F6CFAB.versanet.de] has joined #openttd
22:06-!-HerzogDeXtEr1 [~Flex@i59F6D81.versanet.de] has quit [Ping timeout: 480 seconds]
22:33-!-glx [glx@2a01:e35:2f59:c7c0:3046:2b93:3f65:51db] has quit [Quit: bye]
22:51-!-DDR [~chatzilla@d99-199-14-2.bchsia.telus.net] has quit [Ping timeout: 480 seconds]
22:58-!-KouDy [~KouDy@175.137.102.249] has joined #openttd
23:09-!-DDR [~chatzilla@d66-183-121-60.bchsia.telus.net] has joined #openttd
23:13-!-supermop [~daniel_er@cpe-67-250-2-219.nyc.res.rr.com] has joined #openttd
23:27-!-George [~George@212.113.107.39] has quit [Read error: Connection reset by peer]
23:32-!-George [~George@212.113.107.39] has joined #openttd
---Logclosed Fri Apr 20 00:00:35 2012