IRC logs for #openttd on OFTC at 2012-04-19
⏴ go to previous day
00:33:16 <Nat_aS> there should be an option to scrub specific things like industries and houses from maps without removing everything else
00:33:23 <Nat_aS> perhaps replacing them with markers
00:33:33 <Nat_aS> so you can swap newgrifs without breaking things
01:34:00 *** asdwdfghthr has joined #openttd
01:59:50 *** HerzogDeXtEr1 has joined #openttd
02:22:50 *** kkb110_ has joined #openttd
02:47:59 *** LordPixaII has joined #openttd
04:19:20 *** Pinkbeast has joined #openttd
04:56:18 *** Eddi|zuHause has joined #openttd
05:16:12 *** supermop has joined #openttd
05:19:29 *** telanus has joined #openttd
05:20:51 *** Penguin has joined #openttd
05:22:44 <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?
05:26:27 *** fonsinchen has joined #openttd
05:39:17 *** LordPixaII has joined #openttd
05:43:52 *** Zeknurn has joined #openttd
05:55:42 <NGC3982> it sounds like you had set your trains to autoreplace to an electical engine
05:55:59 <NGC3982> and that might not have taken place until the corresponding depots where changed.
05:56:21 <NGC3982> check your auto replace window.
06:09:38 *** Penguin has joined #openttd
06:16:21 *** mahmoud has joined #openttd
06:25:43 *** kkb110_ has joined #openttd
06:33:41 *** TGYoshi has joined #openttd
06:42:23 *** andythenorth_ has joined #openttd
07:21:12 *** roboboy has joined #openttd
07:40:38 <Rhamphoryncus> NGC3982: well done :)
07:45:20 *** sla_ro|master has joined #openttd
07:56:41 *** peter1138 has joined #openttd
07:56:41 *** ChanServ sets mode: +o peter1138
08:03:30 *** oskari89 has joined #openttd
08:04:02 *** roadt__ has joined #openttd
08:12:19 *** Arafangion has joined #openttd
08:46:04 *** TramOfDeath has joined #openttd
08:46:57 <TramOfDeath> The issue with base music is still not fixed.
08:49:15 <TramOfDeath> base music not loading if it is in content_download. Even the packages that were downloaded by package finder.
08:51:22 <TramOfDeath> OFTC - more like AFKN
08:52:17 <TramOfDeath> OFTC - first-ever IRC graveyard
08:53:12 *** Firartix has joined #openttd
08:55:16 <TramOfDeath> base music downloaded by in-game downloader doesn't load unless moved from downloads to regular.
08:56:18 <Markk> You don't get an answer in about 5 minutes, and you declare the whole network dead?
08:56:55 <TramOfDeath> I am that quick-to-rage
08:59:29 <TramOfDeath> I need a quick fix for this ~@~ -ing bug!!!
09:00:00 <TramOfDeath> It's been 'round since... 1.02?
09:00:23 <Markk> Do you acctually listen to the music in OTTD?
09:01:27 <TramOfDeath> This isn't just for me, this is for keeping things working for OTTD on Puppy Linux.
09:01:35 <Eddi|zuHause> TramOfDeath: so if it's like this for 2 years, what's another few minutes going to kill you?
09:05:16 <TramOfDeath> On Linux, the only fix is to map content_download as the folder above it.
09:05:37 <TramOfDeath> but on Win32, no apparent fix exists.
09:14:06 <Ammler> you could also point him to fs
09:15:57 <Ammler> though, as a packager of a linux distro, he should have known.
09:16:13 <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:17:38 <krinn> the slowdown are because cpu goes 100%, the problem is why cpu goes from 30% to 100% for nothing
09:18:38 <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:19:48 <Ammler> load the title game as normal save?
09:20:30 <krinn> default name/location of the titlegame please so i could load it to see ?
09:21:35 <Ammler> I would guess in <installdir>/baseset
09:23:13 <krinn> done, waiting a bit to see what happen
09:23:36 <planetmaker> krinn: still, please, file a bug report with the available info. Only that makes sure it's not forgotten
09:24:02 <krinn> planetmaker, will do then
09:24:18 <krinn> titlegame is too heavy for my cpu
09:24:43 <krinn> 26405 krinn 20 0 154m 114m 16m R 27,9 3,8 24:37.60 openttd
09:24:53 <krinn> 26405 krinn 20 0 154m 114m 16m R 99,1 3,8 25:03.53 openttd
09:24:53 <krinn> 26405 krinn 20 0 154m 114m 16m R 100,1 3,8 25:06.54 openttd
09:25:06 <planetmaker> but all is fine when you start a new game on your own or load other (older) savegames of yours?
09:26:15 <krinn> and looking at company infos, 3 players with 40~ road vehicle and 2 trains is quiet low
09:27:06 <krinn> and a 4rd with 12 aircrafst... anyway low number of vehicle
09:29:05 <planetmaker> you're also taking about 1.2.0, right? Not trunk
09:29:22 <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:29:52 <krinn> and this savegame is 2048x2048
09:31:41 <krinn> it really looks like the titlegame is doing it only, really strange as no AI, newGRF and map is small
09:39:59 *** FLHerne has joined #openttd
09:49:00 *** FLHerne has joined #openttd
10:02:51 *** TWerkhoven[l] has joined #openttd
10:16:38 <planetmaker> krinn: random shot in the dark, but how does it perform when you start it with ./openttd -b 8bpp-optimized ?
10:16:56 <krinn> answer in sec, restarting
10:17:15 <Eddi|zuHause> planetmaker: the other people in the forum that had similar issues that didn't have an effect
10:17:50 <planetmaker> then it's at least not my imagination that I've heart / seen the issue before :-)
10:17:55 <krinn> for now quiet an improvment, cpu is at 16%-17%
10:18:53 <krinn> looks like it fix the titlescreen, can't get over 19%
10:19:07 <krinn> i'll try loading it as savegame now
10:20:19 <krinn> ok higher, but still running smooth and low: near 25% max now
10:22:28 <krinn> want the ouput as txt to compare ?
10:22:36 <FLHerne> Interesting, mine lags horribly with either blitter :?
10:22:49 <planetmaker> yes, please attach that there, too, krinn. It's valuable info, I think
10:23:15 <planetmaker> just the titlegame, FLHerne or also others?
10:23:39 <FLHerne> In the end, I just replaced it with another savegame
10:23:51 <planetmaker> and that fixes it?!
10:24:14 <FLHerne> I tried loading the titlegame as a normal game, too :P
10:24:21 <FLHerne> That was fine as well...
10:24:46 <planetmaker> you say only when used as titlegame it's eating CPU?
10:24:54 <krinn> look at blitter.txt file in the bug
10:25:13 <krinn> the huge save game with toyland doesn't make that
10:25:17 <FLHerne> It eats my CPU when zoomed out a lot, but most games do
10:25:27 <krinn> and openttd is handling a lot of vehicle in that one on a huge map
10:26:09 <planetmaker> hm, I see. Yes huge games eating cpu when zoomed out is normal
10:26:27 <krinn> i think a bug is hidding itself somewhere, why my cpu could handle toyland savegame and not the "easy" titlegame
10:26:40 <planetmaker> I *can* somewhat understand a difference between 8bpp and 32bpp
10:26:59 <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:27:11 <krinn> you want the ./openttd -b 8bpp-optimized version txt with toyland ?
10:28:49 <planetmaker> krinn: do I see that right that you disabled compile optimizations?
10:29:03 <krinn> from the gentoo patch, yes
10:29:37 *** drac_boy has joined #openttd
10:30:05 <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:30:38 <drac_boy> how're you flherne :p
10:30:49 <krinn> i can rebuild it without the patch if you feel its need
10:30:53 <planetmaker> yes, I looked at your cpuinfo. It should perform significantly better than mine
10:31:17 <planetmaker> you could just check the generic binary, krinn
10:32:00 <krinn> there are static link? i always fail at using them because shared and using old lib versions most binaries distrib use
10:32:08 <planetmaker> it should be, yes
10:32:29 <drac_boy> what doing flherne? :)
10:32:46 <planetmaker> the linux generic binaries
10:32:50 <planetmaker> The others might not, krinn
10:33:23 <krinn> going to try it too, but the going to 100% isn't really because lack of cpu optimization imo
10:33:49 <FLHerne> drac_boy: I'm about to get on with some work...
10:34:07 <drac_boy> heh have fun with that then flherne
10:34:30 <planetmaker> I'd actually be surprised there, too, krinn :-)
10:34:54 <planetmaker> but it's easier to compare :-)
10:35:21 <krinn> lol, damn, missing GRF, sample.cat... wait a few adding them
10:35:58 <planetmaker> uh... you don't have them in you global folder ~/.openttd ?
10:36:24 <planetmaker> makes this stuff so much easier ;-)
10:36:35 <krinn> no, i have put them in my shared folder so all users have them
10:38:02 <planetmaker> but... how can you then have missing sample.cat etc... ?
10:38:08 <krinn> no, it looks the same, goes from 22% to 68.2%, might goes 100% soon with generic binary
10:39:07 <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:41:11 <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:45:15 *** peter1138 has joined #openttd
10:45:15 *** ChanServ sets mode: +o peter1138
10:51:56 <drac_boy> krinn btw what cpu do you have?
10:56:35 <drac_boy> why can't you just tell me?
10:57:00 <FLHerne> Because he has a link that tells you in more detail :P
10:57:14 <krinn> because i would need to remember it and i don't really care, why can't you click ?
10:59:34 <drac_boy> FLHerne problem is its not a link :p
10:59:52 <FLHerne> It looks like one from here...
11:00:05 <krinn> for drac_boy and poor users with lame irc chat program : model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
11:00:21 <drac_boy> krinn..its nothing to do with irc..do you not know what an actual web browser is ;)
11:00:39 <drac_boy> i7...hm...interesting for it to take up that much of a cpu
11:00:56 <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
11:01:23 <drac_boy> krinn I said its nothing to do with irc
11:03:00 <krinn> it take only that much of a core, not the cpu, and it is why i think something is weird there
11:03:21 <drac_boy> weird indeed perhaps
11:04:16 <Ammler> krinn: maybe accidentially using a core, which is also already used by something else? or is openttd really using the whole core alone?
11:04:34 <Ammler> hmm, os should handle that
11:05:35 <krinn> could be that yes, but the balancing is quiet effective on that system
11:05:53 <krinn> in fact, except inside openttd i couldn't notice something is happening
11:06:02 <Rhamphoryncus> telanus: I get that too. No idea what to do about it
11:07:06 <telanus> thought I was doing something wrong
11:07:49 <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:10:04 <telanus> I only get it when starting openttd
11:11:58 <Ammler> krinn: if you use gentoo package, you should report it there or try to reproduce the issue with upstream package
11:12:50 <krinn> Ammler, will do when the package hit the tree, i use a local overlay to build it
11:13:05 <krinn> and the issue still happen with generic binary
11:14:02 <Rhamphoryncus> telanus: It showed up every time I went back to the menu
11:14:07 <Ammler> if you use gentoo, you should also be able to build it self :-)
11:14:36 <krinn> that's what i have done Ammler i just reuse the previous ebuild to made it easy
11:14:50 <Ammler> which might have buggy config/patches
11:14:53 <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:15:40 <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:16:59 <telanus> Rhamphoryncus: seems your right. I never really go back to menu :D
11:17:02 <krinn> using the one i provide in the bug report
11:18:57 <krinn> Eddi|zuHause, tried to break when cpu goes mad : Program received signal SIGINT, Interrupt.
11:18:57 <krinn> 0x08180148 in Blitter_32bppOptimized::Encode(SpriteLoader::Sprite*, void* (*)(unsigned int)) ()
11:19:30 <Eddi|zuHause> krinn: and if you increase the sprite cache?
11:19:53 <krinn> must be in openttd.cfg right ?
11:19:55 <Ammler> hmm, the text file viewer: why is the button called "view readme", but the other just "changelog"?
11:21:13 <krinn> max_sprite_cache_size = 64
11:21:20 <krinn> this one Eddi|zuHause ? to what new value ?
11:21:30 <Eddi|zuHause> anything that is larger :)
11:22:58 <krinn> it goes from 21.3% to 86.2% with 128 set
11:24:39 <krinn> i get max 93.5% now, this is better, but still high
11:24:46 <planetmaker> telanus, Rhamphoryncus you are using the current nightly, right?
11:24:59 <planetmaker> Then it's missing 4 sprites which indicate the happyness of a town with your service
11:25:21 <Eddi|zuHause> krinn: then try something ridiculously large
11:25:24 <Rhamphoryncus> updated openttd a day ago
11:25:37 <planetmaker> (and we still interestingly support in trunk the TTD base set while we do not do that with the open-source alternatives
11:26:23 *** Sludge321 has joined #openttd
11:27:05 <krinn> i've set it to 2048 (i have 3096 only) now 12 to 14% really improving the result !
11:27:32 <Ammler> krinn: meant the configure
11:27:47 <krinn> i mean 2048 in max_sprite_cache
11:28:24 <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:28:26 <krinn> it can't never reach 20% with titlescreen running with it set to 2048
11:28:57 <Eddi|zuHause> so... we needs something to resize the sprite cache...
11:29:21 <krinn> yes, my default (but it's an old old openttd.cfg) was set to 64 and i think i never change it
11:30:25 <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:31:10 <Mazur> My sprite cache size is still on 4.
11:31:21 <Mazur> Which is was originally istalled with.
11:31:41 <krinn> my virtual eaten goes from 147M with 64 set, to 595M with 2048 set
11:33:24 <Mazur> O,wait, that was sprite-cache-size, not max_, which was 64.
11:45:43 *** peter1138 has joined #openttd
11:45:43 *** ChanServ sets mode: +o peter1138
11:47:03 *** roadt__ has joined #openttd
12:05:07 *** ChanServ sets mode: +o petern
12:17:35 *** petern is now known as peter1138
12:24:50 *** roboboy has joined #openttd
12:30:40 *** Sludge321 has left #openttd
12:47:11 *** DanMacK has joined #openttd
13:34:53 *** oskari89 has joined #openttd
13:37:34 *** glx is now known as Guest926
13:37:34 *** ChanServ sets mode: +v glx_
14:06:28 *** TWerkhoven has joined #openttd
14:31:20 *** ChanServ sets mode: +o petern
14:46:46 *** andythenorth has joined #openttd
14:46:47 *** supermop has joined #openttd
14:47:46 *** zxbiohazardzx has joined #openttd
14:47:59 *** zxbiohazardzx has left #openttd
14:49:34 *** goodger has joined #openttd
14:55:07 *** roadt__ has joined #openttd
15:11:54 *** LordPixaII has joined #openttd
15:16:00 *** HerzogDeXtEr has joined #openttd
15:26:11 *** Prof_Frink has joined #openttd
15:57:43 *** tokai|mdlx has joined #openttd
16:04:09 *** Progman has joined #openttd
16:08:45 <andythenorth> offer custom consulting on the codebase too ;)
16:11:17 <planetmaker> yep. DaleStan set good example on the hourly rates ;-)
16:33:34 *** kaenkky has joined #openttd
16:55:41 <krinn> anyone could explain the new destination too far on aircrafts ?
16:56:10 <krinn> it was working fine before, now i see that in orders
16:56:39 <planetmaker> krinn, aircraft can now have a maximum range
16:56:49 <planetmaker> Thus you cannot send it necessarily to every airport
16:56:58 <krinn> per vehicle type range or a global limit ?
16:57:08 <planetmaker> Also orders like A->B->C may fail, if C->A is too far
16:57:14 <planetmaker> it's a per-vehicle type limit
16:57:33 <planetmaker> default it doesn't exist
16:57:57 <krinn> why A->B->C fail because a->c too far? the aircraft will do ab then bc no ?
16:58:27 <planetmaker> Not sure what it does, if A->B and B->C is valid
16:58:36 *** andythenorth has joined #openttd
16:58:57 <krinn> <planetmaker> default it doesn't exist : it's an new option in config ?
16:59:09 <planetmaker> It's a NewGRF property
16:59:20 <planetmaker> Either the NewGRF defines it. Or it doesn't
16:59:28 <krinn> ah ok, so it's no openttd that bug me, just another newGRF so :)
16:59:41 <planetmaker> probably only av8 :-)
16:59:48 <planetmaker> I know no other which uses it ;-)
17:00:04 <planetmaker> but an AI would want to support it
17:00:09 <krinn> that fucking newGRF is a hell for AI
17:00:15 <krinn> always something with it!
17:01:31 <planetmaker> no-one said it was easy ;-)
17:02:02 <planetmaker> what makes it hard?
17:02:30 <krinn> well, nothing, just that now my AI pickup aircraft that are stuck at depot
17:04:47 <planetmaker> The same way that OpenTTD eveloves, NewGRF evolve. And of course AIs then have to evolve, too...
17:05:05 <planetmaker> And the API needs a new 1.2.0 link :-)
17:05:10 <krinn> yeah, but i just see the close point there
17:05:35 <krinn> checking airport->airport tile ok but then airport->depot tile of other airport just 1 tile too far = dead
17:06:08 <krinn> how great! now we will need all depot vs depot vs airport vs airport... combo
17:06:14 <planetmaker> check distance of airports
17:06:56 <krinn> yep, but i must enable a per route aircraft type handling
17:08:32 <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:08:58 <krinn> lol i love your "probably"
17:09:10 <planetmaker> Road-only AIs will not fail
17:09:24 <krinn> until road newGRF put distance limit too
17:09:34 <planetmaker> that won't happen ;-)
17:09:48 <planetmaker> at least I see no reason to add such limit. While it makes sense for air
17:10:07 <andythenorth> ^^ same issues will occur with NoGo
17:10:44 <planetmaker> Every add-on will face sometimes a situation where interaction with another add-on will change things it takes for granted
17:10:54 <planetmaker> and that's exactly what happens here
17:10:55 <andythenorth> is there ever any promise between AI and NewGRFs?
17:11:01 <planetmaker> There's no promise
17:11:05 *** Chris_Booth has joined #openttd
17:11:06 <andythenorth> so this is 'correct'
17:11:09 <andythenorth> rather than 'wrong'
17:11:25 <krinn> the real problem is newGRF take over AI
17:11:26 <planetmaker> AIs are only promised a "best effort" to make available all neccessary info via the API
17:11:35 <planetmaker> krinn, they don't
17:11:48 <planetmaker> The newgrf just implements something not available in earlier versions
17:12:04 <planetmaker> something the AI cannot know or have known before, true
17:12:05 <krinn> well i can't make an AI that wreck a newGRF even with newer API
17:12:10 <planetmaker> But it's by no means a take over
17:12:42 <planetmaker> of course not. But that's for the definition of the two:
17:12:46 <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:12:47 <planetmaker> NewGRF = game ressources
17:13:24 <planetmaker> so the player can never break the game. While the game can break with new rules and behaviour established playing style
17:13:40 <planetmaker> That's not surprising and nothing which even can nor should be changed
17:13:52 <planetmaker> NewGRFs' purpose is to change the way the game works
17:13:57 <krinn> any players (ok maybe not all) can bypass this easy, for an AI, need a rewrite
17:14:16 <andythenorth> it's a "nothing to see here" kind of issue
17:14:30 <andythenorth> filed under "some problems can't be solved"
17:14:50 <planetmaker> krinn, players cannot bypass that at all ;-) They can, similar to an AI, just choose to not play ;-)
17:15:10 <krinn> as of today, that newGRF will broke any AI using aircraft, that's just a fact
17:15:31 <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:15:31 <planetmaker> That's why AIs declare an API version to be compatible with
17:15:38 <planetmaker> though that won't help here, either
17:15:41 <krinn> the AI cannot remove it
17:16:22 <planetmaker> yes, the AI could choose to ignore aircraft if it finds that the established methods don't work
17:16:29 <planetmaker> thus do the same a player does
17:16:48 <krinn> yes, but AI isn't adaptive to new event like that, like a human do
17:16:59 <planetmaker> this of course needs some meta knowledge analysing existing vehicles and stuff
17:17:10 <krinn> hence the AI rewrite to adapt it, not that easy
17:17:22 <planetmaker> yup. That's how it is
17:17:43 <planetmaker> Write it as a module or small library and all AI could profit ;-)
17:17:50 <krinn> and we never get benefits from newGRF nearly :(
17:17:55 *** frosch123 has joined #openttd
17:18:04 <krinn> i cannot query and set another livery/color for an engine per example
17:18:07 <planetmaker> what do you mean with "benefit"?
17:18:12 <andythenorth> AI is not afaict really considered when discussing newgrf specs
17:18:33 <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:18:35 <andythenorth> if AI also had to accounted for, newgrf would basically go int stasis
17:19:15 <krinn> i can't remember the name, but a newgrf for train provide diff spd/power of an engine you could switch too
17:19:23 <krinn> something "benefits" for any players
17:19:51 <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:20:23 <krinn> well, it could save a lot of AI, if something like this one happen again
17:20:28 <planetmaker> anyway, krinn, you're only doing destructive criticism.
17:20:35 <planetmaker> Constructive comments would be well more welcome
17:20:42 <andythenorth> AI authors need to maintain their stuff
17:20:48 <andythenorth> as DaleStan once said
17:20:48 <krinn> what do you expect ? i'm french, we're master at criticism
17:21:01 <andythenorth> "It behooves you to keep up to date in a fast-moving language"
17:21:07 <planetmaker> I expect constructive comments which help your situtations
17:21:21 <planetmaker> other than "NewGRFs suck, they may break my AIs"
17:21:25 <planetmaker> That's not going anywhere
17:21:39 <planetmaker> Nor is "NewGRFs must not implement new game-changing features" a solution
17:21:40 <krinn> saddly there's not, you took care already to provide needed stuff in the API so we could cry but not yell :)
17:21:48 <andythenorth> planetmaker: we *could* insist on backwards compatibility, same as for newgrf spec
17:21:56 <andythenorth> "you may not break existing AIs" ?
17:22:10 <planetmaker> andythenorth, but that means to not change the game rules
17:22:21 <planetmaker> which defies the purpose of new NewGRF features
17:22:41 <andythenorth> not that it's good
17:22:44 <planetmaker> same with new game script capabilities actually
17:22:56 <krinn> at least, a little message in AI forum would have been nice to tell AI author about the new failure
17:23:00 <planetmaker> which might even pose a bigger challange actually for current AIs. No idea
17:23:21 <planetmaker> krinn, then please go ahead. No-one thought of that so far, I guess
17:23:43 <krinn> or no one see it yet no ?
17:23:57 <krinn> i have just discover it today
17:24:02 <planetmaker> not that I know. Not that it may mean that no-one noticed
17:25:37 <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:26:04 <planetmaker> Whatever that may actually be. Finding issues. Reporting issues. Notifying AI authors, writing AI API patches to add things needed,...
17:26:11 <planetmaker> and of course writing and improving AIs
17:26:20 <krinn> i know, i know, i couldn't help myself, else i would
17:26:32 <krinn> but sometimes it looks like newGRF goes too fast vs AI
17:26:39 <andythenorth> high contrast graphics ftw
17:26:49 <krinn> i'm still waiting a way to manage to remove a wagon from a train to place it on another one :/
17:27:21 <planetmaker> like players: separate it. Then add it to new train
17:27:33 <andythenorth> think of all the edge cases to handle there :o
17:27:38 <krinn> ehehe, except we can't click, once sperate the wagon ID is lost
17:27:41 <andythenorth> 'this train needs a brake van'
17:27:52 <andythenorth> 'this wagon can only be attached to train xyz'
17:28:01 <andythenorth> 'this train cannot have more than n wagons'
17:28:10 <andythenorth> it's a tough life for AI authors :)
17:28:47 <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:29:03 <andythenorth> have you tried 'worse is better' ? :)
17:29:33 <krinn> lol i'm scare already this name would be attach to a newGRF
17:30:13 <andythenorth> specifically the example of how UNIX won by handling failures more bluntly
17:30:22 <andythenorth> dunno how it relates here, but it seems to
17:31:02 <andythenorth> planetmaker: fancy adding any FIRS translations? Think there are updates....
17:32:50 <planetmaker> I might do later today
17:33:15 <krinn> planetmaker : that one from MoveWagon -> dest_vehicle_id The vehicle to move the wagon to, or -1 to create a new vehicle.
17:33:37 <krinn> until MoveWagon return the new ID, we're dead at switching engine/wagon from one train to another one
17:34:03 <krinn> and wagons remain lost in depot
17:34:13 <krinn> can't even erase them :/
17:34:48 <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:34:55 <planetmaker> But train building surely needs test building
17:35:02 <planetmaker> It also means that for me myself
17:35:16 <planetmaker> reading readme is for wimps ;-)
17:35:31 <planetmaker> except of course readme, section 4, line 191 ff
17:35:37 <planetmaker> but I know that by heart
17:36:31 <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:36:50 <planetmaker> but you surely can check which vehicles are in the depot?
17:37:28 <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:38:56 <krinn> except of course, sometimes the dummy wagon fail because of the "cannot attach..." :P
17:39:14 <krinn> told you planetmaker newGRF authors put all their efforts at bugging AI authors :)
17:39:32 <planetmaker> of course. Where would otherwise be the fun?
17:40:37 *** andythenorth has joined #openttd
17:41:39 <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:42:26 <andythenorth> it's bound to be in the last place you look ;)
17:43:16 <planetmaker> krinn, that doesn't help me to actually find the cause... once I knew, of course
17:43:50 <planetmaker> the bad thing was that the fig(ure) shows the fit :-P
17:45:47 <CIA-1> OpenTTD: translators * r24154 /trunk/src/lang/ (7 files): (log message trimmed)
17:45:47 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
17:45:47 <CIA-1> OpenTTD: afrikaans - 53 changes by telanus
17:45:47 <CIA-1> OpenTTD: danish - 10 changes by mgarde
17:45:47 <CIA-1> OpenTTD: finnish - 12 changes by jpx_
17:45:48 <CIA-1> OpenTTD: lithuanian - 11 changes by Stabilitronas
17:45:48 <CIA-1> OpenTTD: brazilian_portuguese - 12 changes by Tucalipe
17:49:36 <andythenorth> I'm testing with 256x256 mountainous, rough, high sea
17:49:41 <andythenorth> - all the larger industries have issues occasionally
17:49:56 <andythenorth> - but the only pathological cases are quarry / clay pit - missing on every map so far
17:51:01 <Nat_aS> can you make an industry that can ONLY be placed on slopes?
17:51:12 <Nat_aS> because it would be cool if there was a quarry that was built into a hillside
17:53:35 <andythenorth> Nat_aS: yes, but it's too hard to place, so the game would rarely build it
17:53:45 <andythenorth> Pikka has it in PBI
17:54:46 <V453000> yeah there is always only a few on the map
17:55:57 <andythenorth> come back frosch :P
17:56:30 <andythenorth> if industry was moved to 'something like NoGo', then the problem could be solved
17:57:02 <Nat_aS> well the idea is it would be an alternative sprite.
17:57:24 <Nat_aS> if there are no hillsides, it builds the flat version, if there are no flat spaces, it builds the hillside version
17:57:36 *** telanus1 has joined #openttd
17:57:59 <andythenorth> Nat_aS: you just get the flat one a lot :P
17:58:04 <planetmaker> andythenorth, invent a (much) smaller layout for them or one which fits slopes :-)
17:58:11 <andythenorth> the chances of finding exactly the right hillside is....low
17:58:17 <andythenorth> planetmaker: I'm thinking smaller layout
17:58:22 <andythenorth> or break it into two components
17:58:26 <planetmaker> both. hillside + smaller
17:58:40 <andythenorth> hillside I've been avoiding for ages :P
17:58:48 <planetmaker> It's not like that we can easily add a dozen layouts, if it's modular enough
17:59:04 <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:59:06 <andythenorth> modular is the problem
17:59:16 <andythenorth> a sloped 3x3 quarry means drawing 9 tiles
17:59:18 <Nat_aS> not with flat areas on both sides.
17:59:43 <andythenorth> but the combinations of different slopes means drawing at least 144 tiles iirc
17:59:54 <andythenorth> george has done it for ECS though :P
18:00:07 <andythenorth> and it looks nice in ECS
18:00:22 <planetmaker> but why does it need 144 tiles?
18:00:30 <andythenorth> all the different slope combinations
18:00:37 <andythenorth> I worked it out properly once
18:00:38 <planetmaker> there are 19 slopes
18:00:45 <andythenorth> might be more then :P
18:01:07 <andythenorth> suffice to say, it was lots
18:01:16 <planetmaker> @calc 19 * 5 + 19*4
18:01:17 <andythenorth> although restricting to just, say \ view
18:01:38 <andythenorth> there's no point building on slopes on N side of map
18:01:43 <planetmaker> if you really want arbitrary placement, then it's 171
18:01:52 *** Alberth has joined #openttd
18:01:52 *** ChanServ sets mode: +o Alberth
18:01:58 <andythenorth> I mean the rear face of a hill
18:02:01 <andythenorth> you won't see much :P
18:02:10 <andythenorth> maybe that's the *best* place to build them
18:02:42 <Nat_aS> honestly though, I want to see more scenerios that use industry grfs
18:02:47 <andythenorth> actually, the angle isn't so acute as I though
18:02:53 <andythenorth> you would see most of the quarry
18:03:09 <Nat_aS> so placing industries randomly is not something i care about :P
18:03:09 <planetmaker> Nat_aS, go right ahead and create them ;-)
18:03:11 <Alberth> andythenorth: you are painting for the wrong game :p
18:03:26 <andythenorth> Alberth: would you prefer one with coasters?
18:03:39 <Alberth> RCT goes down at the back without showing any surface
18:04:15 <Nat_aS> I do however need good heightmaps though :P
18:04:51 <andythenorth> surely something 'like NoGo' (as discussed yesterday) would also enable terraforming on industry construction?
18:05:03 <andythenorth> basically, industry grf helper scripts
18:05:14 <Alberth> newgrf should give hints
18:05:27 <andythenorth> bundle a script in the tar with the newgrf
18:05:31 <Alberth> then I am sure openttd can manage without (no)go script
18:05:33 <andythenorth> have it handle the calls from the game
18:06:13 *** Chris_Booth has joined #openttd
18:06:17 <Alberth> or do you want the nogo script to perform terra forming?
18:07:07 <krinn> i love sed ! find . -name "*.nut" -print | xargs sed -i 's/AIOF_/OF_/g'
18:07:09 <Alberth> sounds like the wrong place to me, tbh
18:07:45 <andythenorth> it was a suggestion yesterday
18:07:51 <andythenorth> would also handle closures better....maybe
18:07:55 <andythenorth> maybe not actually
18:08:03 <planetmaker> wasn't the suggestion rather: create a mapgen API? :-)
18:09:51 <andythenorth> currently the clay pit / quarry require all tiles to be absolutely flat
18:10:12 <andythenorth> because foundations at the edges of it look stupid
18:10:21 <andythenorth> maybe it should use 2 tiles
18:10:35 <andythenorth> the centre tiles could be on slopes
18:12:14 *** Alberth1 has joined #openttd
18:12:14 *** ChanServ sets mode: +o Alberth1
18:12:18 *** Alberth1 is now known as Alberth
18:13:29 <Alberth> lol, SElinux killed the network manager for accessing a file, and it took down the connection as well :)
18:18:06 <andythenorth> so...hints from newgrf to terraforming?
18:21:32 <Alberth> wouldn't that be better?
18:24:32 <andythenorth> I should try and figure out if it solves the case
18:24:32 <Nat_aS> hey, when was the ability to join stations with the ctrl key removed?
18:24:57 <andythenorth> the problem is placing industries that need a large flat area
18:25:01 <Alberth> but it won't work if the stations are too far away
18:25:10 <Nat_aS> was it always an option, or did that change?
18:25:28 <Alberth> no change recently there Nat_aS
18:27:58 <Alberth> andythenorth: that's an extreme case, so you'd expect to get trouble in such cases
18:32:43 <andythenorth> Alberth: in that case the work of adding hints is probably tmwftlb
18:32:49 <andythenorth> it wouldn't be simple
18:32:55 <andythenorth> lots of varact 2 needed for them
18:33:13 <andythenorth> the issue is better solved by 'make smaller industries'
18:34:50 <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:35:10 <andythenorth> I can't think of another :)
18:35:23 <andythenorth> it's all we have
18:35:46 <andythenorth> unless the industry layout def is extended in action 0
18:47:16 * andythenorth has to go to the pub though
18:53:27 *** fonsinchen has joined #openttd
19:01:40 <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
19:02:27 <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 ?
19:03:15 <ffpp> hm, the diagram in the game looks way less harsh than the formula in the wiki sounds
19:03:37 <ffpp> or can this be altered by newgrfs ?
19:04:47 <Rubidium> looks are deceiving, and yes
19:12:50 <Rubidium> also the graph in OpenTTD shows about 30% of the cargo payment range
19:12:59 *** Zeknurn has joined #openttd
19:13:48 <Rubidium> and that alone will significantly distort what you see
19:16:13 <ffpp> i know, the scale can distort the look of a graph
19:17: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
19:17:46 <ffpp> but the cargo payment rate graph shows a drop-off in ~50% for passengers over the span of 200 days
19:17:56 <ffpp> that's why I was wondering if there is a difference
19:19:13 <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:19:32 <Rubidium> as described in the cargo income page on the wiki
19:20:06 <Rubidium> so the maximum penalty applies after about 637 days
19:21:38 <Rubidium> hmm, although... the slope's ofcourse different
19:23:30 <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:26:39 <Rubidium> if my math is right, the lowest payment is after 124*2.5 days = 310 game days
19:27:26 <Rubidium> likewise after 200 days you'd be at 47% of maximum payment
19:36:20 *** Rhamphoryncus has joined #openttd
19:51:30 <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
19:53:18 <Rubidium> it does start when the main menu is shown?
19:53:40 <Rubidium> i.e. after the NewGRF/content scan
19:54:40 *** drac_boy has joined #openttd
19:56:01 <fip> no, it doesn't start until the volume control in the music window is touched
20:01:25 <fip> thank's a lot: that looks very promising!
20:06:50 *** peteris has joined #openttd
20:08:11 * Rhamphoryncus accidentally sends his entire fleet for servicing x_x
20:08:53 <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:13:01 <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:16:27 *** Biolunar has joined #openttd
20:20:43 *** frosch123 has joined #openttd
20:30:53 *** bobfred has joined #openttd
20:32:29 *** peter1138 has joined #openttd
20:33:02 *** Chris_Booth has joined #openttd
20:47:17 <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)
22:25:12 <morten> hi, is there enyone here?
22:26:10 <morten> i was wondering if there was someone who could help me install a server on my debian squezze server.
22:45:40 <morten> trying to type: openttd -D
22:46:05 <morten> where do the file get installed?
22:46:25 <Eddi|zuHause> how did you "install" it?
22:49:03 <morten> openttd-1.2.0-linux-debian-squeeze-i386.deb
22:53:45 <morten> or do i have to have a server with a graphical gui
22:56:45 <Eddi|zuHause> your package manager then should have a way to tell you where the files ended up
22:56:54 <Eddi|zuHause> then you need to check whether that place is in your path
22:58:50 <krinn> if openttd is install-> whereis openttd and you'll get your answer
23:00:21 <morten> thanks, sry for being noob :P gotta learn somehow, hehe
23:01:21 <glx> if you want a build without GUI dependancy you need to compile it yourself
23:02:03 <morten> thought something like that now, it asked me for video driver
23:02:26 <morten> or, it says that it can't find graphic set
23:02:50 <glx> graphic set is always required
23:11:52 <heffer> i was always wondering if i can build a gui and non-gui version of openttd in one go?
23:12:14 <heffer> might be interesting for packaging
23:14:18 <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:19:53 <morten> good night, thanks for the help i have gotten
23:26:13 *** brambles has joined #openttd
continue to next day ⏵
