IRC logs for #openttd on OFTC at 2009-03-09
⏴ go to previous day
00:04:54 <Sacro> Dr_B_Ching: you want !password
00:17:36 <Dr_B_Ching> Sacro: sorry - wrong window :( *blush*
00:21:55 *** NightKhaos has joined #openttd
01:06:50 *** Ammler is now known as Guest89
01:23:22 *** Dr_B_Ching has left #openttd
01:25:30 *** goodger has joined #openttd
01:40:47 *** goodger has joined #openttd
02:02:57 *** Klanticus has joined #openttd
02:39:01 *** goodger has joined #openttd
03:12:10 *** TinoDidriksen has joined #openttd
03:17:42 *** roboboy has joined #openttd
03:19:49 *** roboboy has joined #openttd
03:28:44 *** NukeBuster has left #openttd
03:42:25 *** TinoDidriksen has joined #openttd
03:59:42 *** Audigex has joined #openttd
06:17:35 *** Singaporekid has joined #openttd
06:32:18 *** Cybertinus has joined #openttd
07:00:30 <dihedral> congrats on fixing the stupid os x issue
07:03:42 <goodger> someone started a fire in cupertino? :S
07:17:37 *** sigmund_ has joined #openttd
07:52:58 *** stuffcorpse has joined #openttd
08:03:09 *** Cybert1nus has joined #openttd
08:04:57 *** Cybert1nus is now known as Cybertinus
08:13:36 *** Cybertinus has joined #openttd
08:31:19 <dihedral> i always think of CyberTinnitus
08:37:30 * petern rings in dihedral's ear
08:46:49 *** maristo has joined #openttd
08:49:57 *** Vikthor has joined #openttd
08:56:11 *** stuffcorpse has joined #openttd
09:35:28 <dihedral> setting the map_x and map_y settings from 10 to 9 reduces the leak (or what some people think might be a leak) :-P
09:36:21 <dihedral> e.g. in my case, out of memory ocures about 3 hours (plus/minus)
09:36:32 *** racetrack has joined #openttd
09:36:40 <petern> do you have autosave on?
09:36:47 <petern> (does turning that off stop it?)
09:37:39 <planetmaker> petern: he has it on afaik.
09:37:48 <dihedral> i save with autopilot
09:37:49 <dihedral> planetmaker !! i just answered!
09:37:50 <planetmaker> Because the game continues sort-of where it was prior to a crash
09:38:11 <dihedral> yes, what may appear and what is the case aint always the same ^^
09:38:14 <CIA-1> OpenTTD: rubidium * r15649 /trunk/src/core/alloc_type.hpp: -Fix (r15556): don't unnecessarily reallocate
09:38:26 <petern> it's automatically saving...
09:38:34 <planetmaker> well, then it's definitely not an autosave thingy :)
09:38:47 <planetmaker> but still may be a save thingy
09:38:52 <dihedral> ap+ catches kill signals, and for one of those signals ap+ issues a save command on the console
09:39:19 <dihedral> i can turn it off later today
09:42:26 <Rubidium> bah... yapf is allocating so often that you can't quite see other allocates :(
09:46:10 <Rubidium> that I'm not tracking
09:46:11 <petern> i always wondered what managed its cache :p
09:50:09 <petern> while doing the clean up, i also noticed that a lot of it is static methods and variables hidden in classes
09:50:26 <petern> never really bothered looking before
09:54:28 *** elmex_ is now known as elmex
10:02:51 <dihedral> Rubidium: how about a console command for dedicated servers ;-)
10:04:29 <Belugas> "Nintendo,Nintendo... bring a juice for dedicated server1. Hurry up"
10:05:01 <Rubidium> Belugas: go back to bed, it's like 6 o'clock in the morning
10:06:14 <Belugas> i was not able to get out of bed, so my wife hit the shower before me
10:06:30 <Belugas> ho... there she goes!
10:06:34 *** Progman has joined #openttd
10:18:32 <DorpsGek> Rubidium: 4.5045045045
10:43:54 <welshdragon> what a bizarre calculation Rubidium
10:49:09 <[wito]> Is cargodest likely to make it into trunk before 0.7.0?
10:49:30 <dihedral> search the forums for that answer
10:52:34 *** Timitry has joined #openttd
11:00:19 <welshdragon> dihedral: very helpful
11:01:31 <Rubidium> bizarre? 5 minutes * 60 seconds a minute / 2.22 seconds a day / 30 days a month -> 5 minutes is ~ 4.5 months
11:07:04 *** smeding has joined #openttd
11:09:30 <petern> did we ever discover why our ticks are 30ms instead of 27ms?
11:10:21 *** Singaporekid has joined #openttd
11:10:26 <Rubidium> not that I am aware of
11:10:55 <petern> (if that is even the case, heh)
11:10:59 * petern applies Rubidium's patch
11:21:23 <petern> heh, warnings in blob :o
11:23:29 *** TrueBrain has joined #openttd
11:23:49 * dihedral welcomes the TrueBrain
11:23:50 <TrueBrain> I just updated most of openttd.org's software; please let me know if there are any (adnormal) glitches :)
11:24:07 <TrueBrain> (I still need to do git, hg and trac, but .. I am afraid!!! :p)
11:29:00 <TrueBrain> Rubidium: 'powered by leaseweb' was not in the Mercurial templates :p
11:29:45 <petern> powered by dead animals
11:29:53 <TrueBrain> or maybe it was, but debian was so nice to overwrite them
11:30:01 <TrueBrain> debian, or 'apt' / 'aptitude' really sucks
11:30:13 <TrueBrain> no overview, no clear information why something is kept back, .....
11:30:31 <petern> stuff is kept back due to dependencies
11:30:36 <petern> which it tells you about
11:30:37 <Rubidium> it works fine as long as you don't customise stuff ;)
11:30:45 <TrueBrain> petern: haha, you would think .. you know what it told me? (for 10% of the packages)
11:30:53 <TrueBrain> This packages is held back due the following dependencies:
11:30:56 <TrueBrain> (BIG EMPTY SPACE BELOW)
11:31:03 <petern> just dist-upgrade it :p
11:31:38 <Rubidium> does the apt run lenny or testing?
11:31:39 <TrueBrain> but anyway .. it just overwritten some files ... how nice ... how lovely ...
11:32:25 <petern> calloc 1300 bytes at: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7d38455]
11:32:31 <petern> calloc 2880 bytes at: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7d38455]
11:33:00 <Rubidium> then uncomment the strstr(... "(")
11:33:16 <Rubidium> and you'll get openttd [0xdeadbeef]
11:33:50 <Rubidium> do a LDFLAGS="-rdynamic" ;)
11:41:24 <TrueBrain> Rubidium: do you remember where the gitweb templates are located?
11:41:55 *** markk is now known as Markk
11:43:18 <Rubidium> sadly enough I don't
11:46:16 <petern> malloc 2883592 bytes at: bin/openttd(_ZN20CNodeList_HashTableTI14CYapfRailNodeTI20CYapfNodeKeyTrackDirELi12ELi16EE13CreateNewNodeEv+0x69) [0x82eab49]
11:47:43 <petern> well the symbol, yes, but it's just listing the parameters, heh
11:47:56 <TrueBrain> it always makes me smile
11:47:59 <TrueBrain> so no, not a problem ;)
11:48:13 <petern> i have no idea what YAPF stores in that 2.8MB node list...
11:48:25 <petern> seems excessive for a short line
11:51:01 <TrueBrain> okay, git and hg fixed again ..
11:51:16 <TrueBrain> that leaves track .....
11:53:44 <Ammler> Hello TrueBrain, did you ever take a look on Multirepo Branch of trac?
11:54:18 <Ammler> just wondering, but that might mean, no :-)
11:55:01 <TrueBrain> very clear .. tnx for this conversation ..
11:55:06 <TrueBrain> (people are getting more and more weird :p)
11:55:21 <Ammler> well, I was never something else, I guess.
11:57:16 <TrueBrain> I remember I tried to talk some sanity into Moriarty yesterday, about not saying to a person: CHECK THIS! But being a bit more ... well .. explaining
11:57:23 <TrueBrain> I guess I should make that a global announcement or something
11:59:08 <petern> damn, it jumped 8 MB when i wasn't looking :p
11:59:21 <Ammler> TrueBrain: I didn't say, you should check it, I asked if you already did ;-)
11:59:34 <TrueBrain> Ammler: did you ever take a look at NGC-10232?
11:59:46 <Ammler> I have no experience with, I just know there is.
12:00:43 <Ammler> and because we are mixing svn and hg, too.
12:01:21 <petern> you have no experience with?
12:03:57 <Ammler> (and a lot other things...)
12:04:08 <petern> of course, it doesn't increase when i'm just watching it
12:04:29 <planetmaker> murphy has always been good at these things, petern
12:08:00 <TrueBrain> somehow revisionlog is gone in trac ... hmm ...
12:11:04 *** Klanticus has joined #openttd
12:13:52 <petern> but there's no mention in the alloc log
12:15:16 <Rubidium> then it isn't done by a Malloc/Calloc/Realloc
12:18:54 <petern> obviously there's lots of small allocs
12:19:03 <petern> and this constant 2.8MB alloc from yapf
12:19:15 <petern> but nothing that screams "i just allocated 8MB"
12:19:39 <petern> unless at a lower level it's just allocating in chunks of that size
12:19:55 <Rubidium> new isn't handled by my patch
12:23:30 <petern> which would be a little tricky i suppose
12:23:53 <petern> there must be something simple that'll work with LD_PRELOAD...
12:24:47 <petern> i'll see what happens, heh
12:30:04 <TrueBrain> Rubidium: I have NO idea where you did the powered by banner in trac last time :p
12:30:12 <TrueBrain> I can't find a template which when altered reflects on the page :(
12:32:19 <Rubidium> tried /usr/share/pyshared/trac/templates/footer.cs ?
12:32:32 <Rubidium> tried restarting trac once you made the change?
12:32:42 <TrueBrain> couldn't detect a change ...
12:33:36 <TrueBrain> Rubidium: I HTML commented the block left-top now
12:33:39 <TrueBrain> but it is still there ..
12:34:16 <dihedral> does not each project have its own template dir?
12:34:58 <TrueBrain> it does, but if no defined, it should pick the main ..
12:35:49 <Rubidium> what about theme.html ?
12:36:44 <TrueBrain> Rubidium: after a restart, changing that file has some effect yes
12:38:11 <TrueBrain> Rubidium: only leaves an update for mediawiki
12:39:57 <TrueBrain> so now I need a commit to see if everything went as planned ....
12:40:24 <TrueBrain> let me know when there is one ;)
12:46:15 <dihedral> if there were a very large cage, i'd possibly keep a petern as pet ^^
12:46:58 <dihedral> petern: can you tell already what's causing the issue?
12:47:34 *** KenjiE20 has joined #openttd
13:04:49 *** ChanServ sets mode: +v tokai
13:05:56 *** Belugas has joined #openttd
13:05:56 *** ChanServ sets mode: +o Belugas
13:07:02 <CIA-1> OpenTTD: peter1138 * r15650 /trunk/src/newgrf.cpp: -Codechange: Use a ReusableBuffer for loading NewGRF pseudo-sprites into instead of using malloc()/free() for every single one.
13:07:41 <petern> that drops my start up log file from 75MB to 30MB ;)
13:07:56 <TrueBrain> git didn't take up on the commit, and hg fucked up
13:08:21 <petern> didn't add the svn part
13:09:50 *** HerzogDeXtEr has joined #openttd
13:09:55 <TrueBrain> svn: URL 'file:///var/repos/svn/openttd/3rdparty' non-existent in that revision
13:11:01 <dihedral> that was the conversion to hg and git?
13:11:04 *** Brokkoli has joined #openttd
13:11:35 <TrueBrain> Rubidium: the git diff wasn't up-to-date :( :( :(
13:12:51 <TrueBrain> $ git svn rebaseUnable to determine upstream SVN information from working tree history
13:14:44 <petern> bah, a lot of free(NULL) getting logged too :o
13:14:48 * petern ponders fixing the module
13:20:00 <petern> maybe i should just try valgrind, heh
13:20:36 <FauxFaux> You lot are so pro. <3
13:21:42 <FauxFaux> Write, profile, fix.
13:31:51 * Forked throws a banana at the yawn
13:35:41 * TrueBrain catches the banana and eats it
13:38:12 <CIA-1> OpenTTD: peter1138 * r15651 /trunk/src/newgrf_canal.cpp: -Codechange: Codestyle and comments.
13:38:59 <TrueBrain> at least mercurial is now doing what it should be doing :)
13:39:43 <Forked> yellow banana tasting like a green one. meh
13:40:04 <TrueBrain> I love green bananas :)
13:41:47 <TrueBrain> # beep beep beep beep
13:45:23 <petern> "my email's not working, please advise"
13:45:32 <petern> unfortunately i'm not allowed to say
13:45:45 <petern> "PLEASE COPY THE FUCKING ERROR MESSAGE YOU FUCKING IMBECILE"
13:46:02 <Forked> did he or she email you the question? :)
13:47:46 <TrueBrain> petern: I feel your pain ..
13:49:29 <petern> unfortunately i wasn't watching it :p
13:50:32 <SmatZ> petern: does to log new/delete too?
13:51:33 <petern> i'd always assumed new/delete used malloc/free behind the scenes, but i guess not :o
13:52:37 <TrueBrain> petern: overload them to force malloc/free usage ;)
13:57:46 <petern> it logs 2 mallocs and 2 frees for that
14:10:40 *** NukeBuster has joined #openttd
14:11:00 *** NightKhaos has joined #openttd
14:20:50 <petern> valgrind doesn't say much, harder to see if it's leaked though :o
14:23:32 *** Swallow has joined #openttd
14:25:06 * Belugas plucks Sacro's leak with a cactus
14:25:59 * petern wonders why valgrind complains about newgrf_spritegroup.cpp:214 twice
14:26:20 <petern> Conditional jump or move depends on uninitialised value(s)
14:26:29 <petern> and which value is uninitialised...
14:35:14 *** Combuster has joined #openttd
14:35:34 * glx is trying to compile with _malloc_dbg and friends
14:36:17 <glx> but the preprocessor doesn't like Queue->Free()
14:36:47 <glx> it replaces some "free" with "_free_dbg"
14:45:20 *** Dred_furst has joined #openttd
14:51:28 *** Belugas has joined #openttd
14:51:28 *** ChanServ sets mode: +o Belugas
15:03:37 <Zahl> do you build yourself on windows?
15:04:24 <SmatZ> I don't have windows here
15:05:05 <SmatZ> one meter from me :) but I don't have build environment there
15:05:23 <SmatZ> like, it's a "company's" laptop, and I am not sure about legal things
15:05:55 <SmatZ> Zahl: why are you asking?
15:06:11 <Zahl> i might have found something but i need someone to validate
15:06:20 <Rubidium> I wouldn't build myself on Windows; chances are too high that something breaks compilation, after all... when I was born Windows wasn't invented yet
15:06:54 <Rubidium> so I doubt there's any Windows support in my source
15:07:02 <Zahl> ok i'll try something different then :>
15:07:05 <SmatZ> Zahl: try asking glx or michi_cc or Yexo :)
15:07:29 <Zahl> do you know what the nightlies for windows are compiled with?
15:07:32 <Yexo> Zahl: what was the problem?
15:08:02 <Rubidium> MSVC 2008 for 32/64, mingw for 9x
15:08:02 <Zahl> Yexo: its about the memory issue on windows
15:10:04 <SmatZ> glx: are those really leaks? maybe you could try "#define MallocT" instead of "#define malloc" so it prints out where MallocT was called... I haven't seen the diff though :)
15:10:24 <Zahl> i tried a tool named "memory validator" yesterday... it told me something funny
15:11:23 *** pavel1269 has joined #openttd
15:12:02 <SmatZ> glx: aha, interesting :)
15:12:30 <glx> free -> Free changes are just to allow compilation ;)
15:12:40 <SmatZ> actually, MallocT<> can't be #defined :-x
15:12:51 <SmatZ> maybe search & replace...
15:13:29 <Rubidium> you could also play tricks like I did on MallocT
15:14:53 <SmatZ> Rubidium: can backtrace() be used to give nicer crash dumps for linux?
15:15:21 <SmatZ> when -O2 and such is used...
15:16:36 <Rubidium> unlikely; information about what function is where is probably lost
15:16:38 <petern> ==16051== LEAK SUMMARY:
15:16:38 <petern> ==16051== definitely lost: 25 bytes in 4 blocks.
15:16:38 <petern> ==16051== possibly lost: 720 bytes in 5 blocks.
15:16:38 <petern> ==16051== still reachable: 7,372,020 bytes in 18,452 blocks.
15:16:38 <petern> ==16051== suppressed: 0 bytes in 0 blocks.
15:17:31 <SmatZ> petern: nothing new I am afraid
15:17:35 <glx> hmm I could try visual leak detector
15:18:06 <petern> well, i had a 3GB virtual size after running a server for 2 weeks
15:18:11 <petern> maybe i should just give it more time
15:18:39 *** Dred_furst` has joined #openttd
15:18:46 <Rubidium> definitely lost is probably in SDL's init
15:19:18 <SmatZ> Rubidium: or that videodriver, soundriver, blitter variables in ttd_main()
15:19:59 <SmatZ> it can as well be memory that is allocated but freed at exit so it is not marked as leak...
15:20:18 <petern> yes, my output shows no leaks, essentially. not in order of 3GB...
15:22:51 <petern> SmatZ, we've already discussed and decided that freeing every single bit of memory before exit is pointless
15:23:04 <petern> (the only use is to appease valgrind et al)
15:23:35 <TrueBrain> petern: it does make it easier to detect real leaks though ;)
15:23:52 <Rubidium> TrueBrain: in what sense?
15:24:08 <TrueBrain> Rubidium: shorter runs
15:24:30 <TrueBrain> when you free everything at closure
15:24:37 <TrueBrain> and you run valgrind, which shwos things not freed
15:24:42 <TrueBrain> there is a good chance it would have leaked over time
15:25:00 <TrueBrain> in my personal projects I solved many potential memleaks that way :)
15:25:09 <Zahl> downloaded the win9x nightly and it has steady memory usage on the 500trains savegame
15:25:40 <Rubidium> Zahl: and not with the MSVC (win32) binaries?
15:26:02 <Zahl> i am running both builds right now
15:26:17 <Zahl> loaded the same savegame
15:27:01 <glx> Zahl: do you want a win32 gcc build too ?
15:28:19 *** lewymati has joined #openttd
15:29:16 <Zahl> isn't the win9x version win32?
15:29:35 <glx> it is but unicode is disabled
15:30:16 <Zahl> well i guess the result here is already speaking for itself :-D
15:30:29 <Zahl> or do you think its a unicode issue?
15:31:00 <Zahl> because if it is a bug with msvc, the output of the tool i used yesterday might actually make sense
15:31:12 <Zahl> it would be the sdt::list that is leaking then
15:32:45 <Zahl> it said every instance would leak 12 bytes and highlighted the line where the list of packets is defined
15:39:03 <Rubidium> so with MSVC is leaks and with MinGW it doesn't... interesting
15:39:39 <Aali> MSVC always had a shitty STL implementation..
15:40:08 <glx> I had to change AI API to not use reverse iterators
15:40:23 <michi_cc> cargopacket.cpp:209 maybe? clear() won't free the memory from the cargo packets
15:40:53 <michi_cc> or will the MoveTo() in front take care of that?
15:41:43 <Zahl> it has to, otherwise it would leak everywhere
15:42:31 <michi_cc> no, because most of the time all packets can probably be delivered so the code path isn't reached
15:42:48 <Zahl> i mean like, on every platform and with every compiler
15:43:03 <petern> the MoveTo takes care of it
15:43:23 <glx> visual leak detector output is better
15:43:28 <SmatZ> petern: the discussion was about freeing data marked as "still reachable", this is marked as "definitely lost" - there have been several commits (not from me) fixing those one-time leaks already
15:44:10 <Rubidium> Zahl: since (approximately) when did you notice the leaky behaviour?
15:44:17 <Rubidium> i.e. does it happen in 0.6.3?
15:44:39 <Zahl> Rubidium: i have to check that, i didn't play ottd in ages
15:44:48 <Zahl> i'm gonna try some older versions
15:46:50 <petern> i hadn't run a server for ages, but don't remember a leak in 0.6.3
15:51:50 <glx> uncompressed version is available too
15:53:55 <SmatZ> glx: I am afraid this includes those "still reachable" memory block, am I right?
15:54:32 <glx> dunno vld docs are not very explicit
15:55:22 <petern> what makes you think the 'leaked' memory is unreachable?
15:55:47 <petern> (yes, that's the definition of leak)
15:56:19 <Rubidium> SmatZ: yes, it includes "still reachable"
15:56:27 <Rubidium> such as the 4 MB sprite cache
15:56:53 <Rubidium> with all 4 MB of data
15:57:09 <Rubidium> at 16 bytes a line ;)
15:58:25 <glx> it also includes sound bank
15:58:47 <Rubidium> A total of 3 leaks match this size and call stack. Showing only the first one.
15:58:48 <Rubidium> f:\dd\vctools\crt_bld\self_x86\crt\src\realloc.c (323): _realloc_base
15:58:48 <Rubidium> f:\dd\vctools\crt_bld\self_x86\crt\src\dbgrealloc.c (60): realloc
15:59:20 <Aali> well, just let it run for a week and find the line that says "A total of 2 bazillion leaks match this size and call stack" :)
15:59:23 <SmatZ> petern: valgrind says so... local variables musicdriver, sounddriver, videodriver, blitter, graphics_set are on stack, thus the memory they point to is marked as unreachable in valgrind after ttd_main has finished
15:59:43 <glx> Aali: I did a simple launch and exit
16:00:48 <petern> SmatZ, uh, okay, i'm trying to find out why my virtual size got up to 3GB. i'm pretty sure it's not those few variables...
16:01:00 <Aali> 0.5.3 does not seem to leak
16:01:26 <Aali> its holding at 7744k private bytes
16:01:41 <Aali> while 0.6.3 is at 30700k and growing
16:01:45 <TrueBrain> petern: virtual size, as VMZ? against RSS?
16:01:53 <Aali> both running the intro game
16:01:55 <Rubidium> Aali: you compile yourself?
16:02:05 <Aali> Rubidium: nope, fetched those from the site
16:02:22 <TrueBrain> petern: RSS is the real memory usage .. I tend to ignore VMZ :p
16:02:27 <Rubidium> Aali: can you compile yourself, with MSVC?
16:02:33 <petern> TrueBrain, me too, but 3GB is excessive
16:02:56 <TrueBrain> petern: I tend to agree
16:03:07 <TrueBrain> root 9250 0.0 1.5 222088 12360 ? Ss 11:51 0:00 /usr/sbin/apache2 -k start <- 220 MiB of VMZ, where only 12 MiB of RSS
16:03:11 <TrueBrain> sometimes I just don't get it :p
16:03:36 <petern> lots of unaccessed pages
16:03:45 <petern> 21318 hlds 20 0 283m 189m 24m S 1 4.7 665:34.21 srcds_i486
16:04:15 <TrueBrain> mine has a 20:1 rating
16:04:23 <Zahl> anyone got old saves with lots of trains?
16:05:01 <SmatZ> can the problem be SetBankSource (maybe MX_AUTOFREE not correctly set or so)?
16:05:02 <Zahl> yeah but they are full of newgrfs and stuff
16:05:09 <Zahl> sunno if its good to test with those
16:05:29 <Rubidium> pile transport isn't
16:05:36 <SmatZ> Zahl: does it leak when you run -s null -m null ?
16:05:45 *** Swallow has joined #openttd
16:06:31 <SmatZ> hmm most likely that's not the problem
16:09:04 <TrueBrain> petern: btw, 64bit or 32bit? (sorry, didn't feel like backreading :p)
16:15:11 <TrueBrain> btw, petern, ever tried pmap on the process when it consumes such an amount of VMS?
16:15:18 <TrueBrain> grr ... stupid 3 letter words :p
16:17:10 *** pavel is now known as pavel1269
16:17:32 <petern> i'm watching pmap at the moment ;)
16:17:40 <petern> i get a ton of lines with 8192K allocated
16:19:09 <TrueBrain> that are big blocks :p
16:20:40 <[wito]> anyone tried patching 0.7.0b with CargoDest?
16:21:37 <Aali> Rubidium: 0.5.3 compiled with VC 9 is not leaking
16:21:53 <TrueBrain> hmm ... am I the only one unable to connect to the content service?
16:22:54 <glx> TrueBrain: fails for me too
16:23:23 <TrueBrain> maybe it didnt reconnect to the mysql :p
16:23:59 <Rubidium> TrueBrain: the web-test server is running
16:24:19 <TrueBrain> and the live one crashed badly
16:24:21 <TrueBrain> memory corruption ..
16:26:03 <TrueBrain> Rubidium: ottd_master and ottd_updater survived the mysql reconnect (or so it seems)
16:26:07 <TrueBrain> ottd_content didn't :p
16:26:26 <Rubidium> no idea why it didn't
16:26:43 <TrueBrain> no idea eiterh ;) Just relaying :)
16:27:06 <Rubidium> just kill the web-test binary so you won't be confused next time ;)
16:28:22 <Rubidium> and in more than 5 hours nobody has missed it ;)
16:30:09 <Zahl> Rubidium: 0.5.3 seems fine
16:30:30 *** Ammler is now known as Guest199
16:30:50 <Zahl> oh i see, Aali tested it too :)
16:32:09 <Rubidium> if Aali tests r10266 you can test r10265; just to test whether it can be the cargolist that's leaking
16:34:20 *** stillunknown has joined #openttd
16:34:27 <Aali> r10266 is extremely leaky
16:35:08 <Rubidium> the st type of towels?
16:35:52 <petern> is it extremely leaky just because the pool wasn't cleared on exit though?
16:36:13 <Aali> r10266 ate 2MB in one minute
16:36:55 <Rubidium> now the question is does 10265 the same?
16:37:53 <pavel1269> u know, i am also sometimes ver yhungry :-)
16:38:15 <TrueBrain> and how do you test if it is leaking Aali?
16:38:33 <Aali> I let the intro game run in ff
16:38:41 <petern> oh crap, my copy has used memory while i wasn't looking :p
16:39:07 *** Guest199 is now known as Ammler
16:39:49 <TrueBrain> I guess it is MSVC only which leaks?
16:40:22 <TrueBrain> petern: go to the badroom :p
16:40:30 <TrueBrain> petern: anyway .. what compiler / how does it leak?
16:40:57 <TrueBrain> petern: how to reproduce?
16:41:00 <TrueBrain> as it is very stable here :)
16:41:38 <Zahl> i set up a linux dedicated a few days ago and got the same thing like petern btw...
16:41:52 <Zahl> but right now it looks like these are two different issues
16:42:04 <Zahl> i mean windows msvc and VSZ on linux
16:42:26 <pavel1269> is possible with MSVS 9/2008 to apply patch?
16:42:41 <petern> you apply patches with the patch command
16:43:11 <TrueBrain> petern: I mean, does it happen only in networking, or also a normal game, or?
16:43:15 <Zahl> pavel1269: i think the easiest way on windows will be tortoisesvn
16:43:59 <petern> it happened on my dedicated server after 2 weeks running
16:44:07 <Aali> r10265 leaks aswell, but not nearly as much as r10266
16:44:08 <petern> i didn't watch it during that time
16:44:24 <pavel1269> does tartoise also create .rcc or sth like that if he fails appling a patch?
16:44:24 <TrueBrain> petern: k .. that sucks :)
16:44:47 <Rubidium> so that kinda proves that (large) part of the curent problem comes from there
16:45:18 <petern> memleaks in 10266 may well have been accidentally fixed
16:45:21 <Rubidium> now the real question is how to solve it and what part of r10266 actually causes it
16:45:38 <TrueBrain> I agree with petern, it might be long fixed ..
16:46:09 <Rubidium> true, but there are quite a few clues that it might be caused by that
16:46:13 <Aali> r10265 may not even be leaking at all, its so slow it could just be the natural progression of the game
16:46:15 <petern> ==628== definitely lost: 17 bytes in 1 blocks.
16:46:15 <petern> ==628== possibly lost: 0 bytes in 0 blocks.
16:46:16 <petern> ==628== still reachable: 5,492,910 bytes in 605 blocks.
16:46:16 <petern> ==628== suppressed: 0 bytes in 0 blocks.
16:46:24 <petern> after running -v null:ticks=10000
16:46:38 <michi_cc> my win64 msvc binary doesn't leak a bit, so it's not just simply msvc alone
16:46:38 <TrueBrain> glx: your map had 544 statiosn, 226 vehicles and 26 effect vehicles when closing the game :p
16:46:39 <Rubidium> ofcourse you're free to give any other clues that you've got w.r.t. the MSVC leak problem
16:46:39 <Zahl> Aali: thats what i think, it increased by 800k here now, running for 10 minutes in fast forward
16:46:52 <SmatZ> petern: did you use --leak-check=full to see where the leaked memory was allocated?
16:47:21 <Zahl> 2094 (in that savegame from ottdcoop)
16:47:24 <glx> TrueBrain: I just started openttd and exit immediatly
16:47:31 <Aali> oh, you're not running the intro game..
16:47:41 <TrueBrain> glx: then it is a bit more odd ;)
16:51:05 <SmatZ> petern: it seems all the memory is still reachable in that paste
16:52:16 <petern> so the intro game does not leak for me
16:52:42 <SmatZ> [17:46:22] <petern> ==628== definitely lost: 17 bytes in 1 blocks. <== I thought this one was interesting :) but you probably know it isn't harmful
16:52:43 <TrueBrain> petern: put your server in a valgrind and wait 2 weeks ;)
16:54:08 <petern> incidentally, "null:ticks=10000" is 17 bytes long
16:55:42 <petern> TrueBrain: i may just do that :p
16:57:12 <TrueBrain> running dbg lvl3 and valgrind -vnull:ticks=1 takes .. well .. LONG :p
16:57:27 <Rubidium> TrueBrain: remove your newgrfs
16:57:37 <TrueBrain> good posibility they are still there ..
16:57:46 <Zahl> Rubidium: no that patch doesn't help
16:57:59 <Zahl> but i found something else that helps
16:58:13 <Rubidium> so it isn't michi's idea that tmp.packets.clear() was the problem
16:59:05 <Zahl> i removed the call to HandleLocomotiveSmokeCloud in train_cmd.cpp
16:59:14 <TrueBrain> Rubidium: doesn't really help :p
16:59:58 <Rubidium> TrueBrain: what doesn't really help?
17:00:06 <glx> Zahl: so you mean it's in effects
17:00:36 <Zahl> glx: if memory validator is right, its still the std::list in CargoList
17:00:53 <Zahl> HandleLocomotiveSmokeCloud created an EffectVehlice
17:00:54 <SmatZ> or generally less vehicles are created, so it allocates less memory...
17:01:06 <Zahl> which is derived from Vehicle.. and Vehicle creates a CargoList
17:01:08 <TrueBrain> Rubidium: removing my newgrfs
17:01:13 <glx> Zahl: EffectVehicle have cargolist
17:01:17 <Zahl> and with lots of trains this gets called very often
17:01:19 *** energetic has left #openttd
17:01:30 <petern> SmatZ, bring out your clean-up-every-last-bit-of-memory patch
17:01:44 <petern> that'll fix the "the pool's bigger" "leaks" ;)
17:02:07 <SmatZ> petern: good idea, I have to update it to trunk though :)
17:02:30 <TrueBrain> 51 kib of memory for ChatMessage, in single player?! (or worse: in main-menu)
17:02:51 <Zahl> glx: actually i think i'm gonna add some code to create 50000 instances of CargoList and delete them again and see if it leaks
17:03:28 <petern> _chatmsg_list = ReallocT(_chatmsg_list, _settings_client.gui.network_chat_box_height);
17:03:40 <TrueBrain> if (!_networking) maybe? :p
17:03:54 *** |Jeroen| has joined #openttd
17:04:12 <Zahl> petern: and then build a dedicated server without network support :p
17:04:30 *** [com]buster has joined #openttd
17:05:50 <TrueBrain> Rubidium: btw, if a patch as you just presented would really fix it, gcc should show the same problems
17:06:10 <Rubidium> TrueBrain: not if MSVC's std::list implementation is broken
17:06:33 <glx> hmm real vehicles have this->cargo.Truncate(0); in the destructor
17:07:08 <glx> but I don't know if it's important
17:07:11 <Rubidium> on the other hand effect vehicles don't get cargopackets
17:07:18 *** [com]buster is now known as Combuster
17:07:34 <glx> but cargo is allocated on construction
17:07:52 <TrueBrain> cargolist, yes, cargopackets, no ;)
17:08:08 *** energetic has joined #openttd
17:08:20 <TrueBrain> cargolist, std::list<cargopackets *> and cargopackets .. you got to love it :)
17:08:42 <TrueBrain> btw, Rubidium, if you think std::list is in error here, can't you replace it with one of the Simple thingies OpenTTD has?
17:08:52 <TrueBrain> SmallVec or what ever?
17:12:15 <TrueBrain> I guess it takes little effort to make it enough for its usage in cargopackets.cpp
17:12:18 <Rubidium> but could use it for poc
17:13:49 <TrueBrain> (I don't mean a correct implementation, but just one to test if it is a problem or not ;))
17:14:26 <Zahl> i think it also cannot just be the list leaking in general, it has to be special circumstances, as the list is used in other places too
17:17:03 <TrueBrain> petern: I really wonder how your VSZ exploded like that :)
17:27:27 <petern> assuming they're openttd processes
17:28:58 *** MrFrans has joined #openttd
17:40:56 <Zahl> Rubidium: as far as i can tell its solved. there's still a slight increase over time which seems to be the gamestate getting bigger.. if its still leaking, its at least much less...
17:41:42 <Rubidium> yay for std::list :(
17:43:26 <Zahl> i tried allocating and then deleting 100000 CargoList in in the "resetengines" console command earlier, but that doesn't leak for some reason
17:44:03 <Rubidium> probably because you didn't put stuff in the cargolists
17:44:26 <Zahl> yeah, but for the EffectVehicles there should also be nothing in there..
17:44:35 <Zahl> still they trigger the leak
17:46:37 *** [com]buster has joined #openttd
17:46:40 *** [com]buster is now known as Combuster
17:47:29 *** frosch123 has joined #openttd
17:56:38 *** [1]KenjiE20 has joined #openttd
17:56:46 <planetmaker> hello Mr Belugas :)
17:57:01 *** KenjiE20 is now known as Guest211
17:57:01 *** [1]KenjiE20 is now known as KenjiE20
17:57:28 <pavel1269> lo mr planetmaker :-)
17:58:44 <el_en> nd: Lidl's Freeway MixxMax (cola & orange)
17:59:24 <planetmaker> :D Same here, same here... still :S
17:59:28 <pavel1269> in my country we have nice "nursery rhyme" .... "why are u
18:00:03 <pavel1269> "why do u use first-anme thersm, we havent peed together"
18:00:15 <pavel1269> hope u will understand that
18:02:15 <Belugas> nursery rhyme... i'd rather go for "Nursery Crime"!
18:02:29 <planetmaker> :D sounds like :P
18:02:40 <michi_cc> Zahl: I've got another idea, can you replace line 611 in vehicle.cpp ("new (this) InvalidVehicle();") with "this->type = VEH_INVALID;" and report what's happening?
18:02:49 * planetmaker hands Belugas a "o" :P :)
18:02:53 <pavel1269> why do YOU hate "u" so much?
18:03:01 <planetmaker> I take "u"s into comission ;)
18:03:07 <planetmaker> pavel1269: it's ugly reading
18:03:18 <pavel1269> hmm, its fast typing :-)
18:03:46 <pavel1269> but u kno what i mean
18:04:12 *** pavel1269 was kicked by Belugas (Do you know wnat I mean?)
18:04:17 <planetmaker> pavel1269: it's simply _not_ readable :D
18:04:26 *** pavel1269 has joined #openttd
18:04:30 <planetmaker> pavel1269: it's simply _not_ readable :D
18:04:35 <FauxFaux> Belugas: "It's ugly." is closer to accepted English.
18:04:38 <michi_cc> Rubidium: that line in vehicle.cpp looks very suspicious, as InvalidVehicle() will create a new CargoList instance without the destructor of the old one being run
18:04:55 <FauxFaux> Not mentioning the contraction of "it is". I mean, pure sloth, right there.
18:05:08 <yorick> pavel1269: that's a typo
18:05:19 <yorick> FauxFaux: it is accepted english
18:05:44 <FauxFaux> Oh, indeed. I'll happily accept "I'd've" and the like.
18:05:45 <yorick> pavel1269: the h is right next to the n
18:06:08 <yorick> but the u key isnot close to the you key
18:06:20 <yorick> I don't even have a you-key
18:07:13 *** Mortomes has joined #openttd
18:07:16 <FauxFaux> Calm down dear, it's the any key.
18:11:12 *** pavel1269 has left #openttd
18:11:18 *** pavel1269 has joined #openttd
18:13:49 <Zahl> Rubidium: we can keep our beloved std::list it seems
18:14:21 <Zahl> (if this didn't break something else)
18:18:24 <Zahl> you stay right here buddy
18:19:45 <Aali> so, EffectVehicle was fucking it up all along
18:20:34 <Aali> (or any other vehicle, but you don't destroy those as often)
18:21:19 <Zahl> yeah that, in some wierd combination with the std::list
18:21:20 <Aali> if anyone ever played with disasters on
18:21:31 <glx> but indeed effects are the visible part of the iceberg :)
18:22:33 <[wito]> How do I invoke the configure script as for to use /usr/share/ instead of /usr/local/share?
18:25:54 <Forked> Rubidium: no silly, that just brings up the "this is how you do it" list. geez :\
18:26:31 *** Frostregen has joined #openttd
18:30:00 *** tkjacobsen has joined #openttd
18:34:49 *** Alberth has joined #openttd
18:35:48 <petern> whatever's causing my vsz thingy is not lost memory :o
18:36:04 <petern> or i just didn't leave it long enough
18:42:08 <CIA-1> OpenTTD: michi_cc * r15652 /trunk/src/vehicle.cpp: -Fix [FS#2706]: new (this) is seldom a good idea as destructors of member variables aren't run causing memory leaks.
18:42:29 <[wito]> r15651 with cargodest!
18:43:09 <[wito]> of course, now I'll have to update from subversion and build again. :P
18:43:19 <CIA-1> OpenTTD: translators * r15653 /trunk/src/lang/ (6 files in 2 dirs): (log message trimmed)
18:43:19 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2009-03-09 18:42:57
18:43:19 <CIA-1> OpenTTD: dutch - 1 fixed by habell (1)
18:43:19 <CIA-1> OpenTTD: german - 1 fixed by planetmaker (1)
18:43:19 <CIA-1> OpenTTD: luxembourgish - 387 fixed by Gubius (387)
18:43:21 <CIA-1> OpenTTD: romanian - 1 fixed by kkmic (1)
18:43:21 <CIA-1> OpenTTD: thai - 29 fixed by meemee1983 (29)
18:44:21 <pavel1269> cargodest in trunk?
18:44:33 <DorpsGek> yorick: Commit by peter1138 :: r15651 trunk/src/newgrf_canal.cpp (2009-03-09 13:38:00 UTC)
18:44:34 <DorpsGek> yorick: -Codechange: Codestyle and comments.
18:45:11 <Belugas> i guess wito means that he upgraded cargodest to r15651...
18:45:29 <DorpsGek> el_en: tron was last seen in #openttd 1 year, 4 weeks, 0 days, 5 hours, 22 minutes, and 1 second ago: <Tron> gcc 2.95 is plain obsolete (even has several bugs in its C++ part). further at the very least the justifications given are extremely oversimplified.
18:45:32 <yorick> don't scare me like that
18:45:57 <[wito]> seems to work well enough with 15651 so far, tho'
18:46:04 <pavel1269> yorick: scare? why?
18:46:19 <yorick> cargodest hasn't been updated for 2 months and had some desync
18:46:58 <Belugas> which, by many standards, means it's ready for trunk inclusion :P
18:47:12 <Belugas> twweeeeet twiiiiiiiiiiiiiit
18:47:25 <Belugas> sarcasm detector gone crazy!!!!
18:47:51 <planetmaker> I saw a smoke cloud where I last saw that detector. Did something happen to it?
18:48:03 <Ammler> yorick, those desync were trunk related and are fixed.
18:48:09 <pavel1269> u'v just killed that patch for me
18:48:12 <Belugas> i swallowed the smoke
18:48:33 <pavel1269> that is just great! :-)
18:48:37 <Ammler> aali's patch is quite stable.
18:48:48 <pavel1269> what does mean, quite? :P
18:49:01 <planetmaker> it's usually quiet :P
18:49:29 <planetmaker> Ammler: your spelling was correct :)
18:49:33 *** tkjacobsen_ has joined #openttd
18:50:09 <yorick> pavel1269: "quite" "more than a bit"
18:50:24 <pavel1269> i know that word ... just .... :-)
18:50:39 <pavel1269> it IS stable or ISNT :-)
18:50:53 <Ammler> openttd is indeed stable
18:51:07 <pavel1269> my patch is semi-working :-)
18:52:12 <Ammler> it was never that stable like now, imo. (except the memory which is something else)
18:52:42 <planetmaker> I haven't seen a single desync (nasty stuff!) since autumn, I think
18:53:06 <Ammler> do you miss them too ;-)
18:53:07 <planetmaker> and the few asserts since then were quickly fixed.
18:53:14 <pavel1269> my last desync was in ..... long .... when it was almost impossible to buy industry :-)
18:53:35 <pavel1269> buy industry ... 50% to desync .... when was that?
18:53:41 <planetmaker> Ammler: not sure :) I think it's one of the things which I like to keep as "bad memory of the past" ;)
18:54:16 <planetmaker> so... not everything was better in former times :D
18:54:28 <yorick> how to get company id from Company object?
18:54:42 <planetmaker> GetCompanyID(object)?
18:54:57 *** tkjacobsen__ has joined #openttd
18:54:58 <planetmaker> or rather o->GetCompanyID()
18:55:42 <yorick> and also it isn't true
18:55:43 <planetmaker> Openttd uses preferably convoluted, unreadable code ...
18:55:54 <Belugas> [14:54] <planetmaker> I haven't seen a single desync (nasty stuff!) since autumn, I think <--- I have not seen a desynch for at least 2 years ;)
18:56:09 <yorick> Belugas hasn't played openttd for at least 2 years
18:56:22 <Belugas> a cookie for the Y man
18:56:47 <Ammler> just eaten the last one
18:56:49 <planetmaker> I wish I could say that, but my openttd history isn't as long :)
18:57:03 <CIA-1> OpenTTD: frosch * r15654 /trunk/src/ (articulated_vehicles.cpp roadveh_cmd.cpp): -Fix: Only ever call any vehicle callbacks after the whole articulated engine has been built. (except 0x16)
18:58:59 <Aali> why do the newgame grf settings affect old savegames?
18:59:42 <planetmaker> Aali: maybe some settings weren't defined back then?
18:59:54 *** Yeggzzz is now known as Yeggstry
18:59:56 <Aali> still seems like a bad idea
19:00:03 <Ammler> Aali: pre-grfsettings-insave-games
19:00:21 <planetmaker> you then need to go by some value.
19:00:21 *** tkjacobsen has joined #openttd
19:01:09 <Aali> so, you could have newgrfs in a game, but the config wasn't stored in the savegame?
19:01:16 *** Klanticus has joined #openttd
19:01:28 <Ammler> how long do you know openttd?
19:01:38 <Ammler> that isn't that long ago.
19:01:50 <Rubidium> planetmaker: can I join your with the slapping party?
19:02:03 <Aali> I started playing ottd with 0.6.2
19:02:07 <planetmaker> Rubidium: you're always welcome at my parties :)
19:02:36 <Rubidium> Ammler: 0.5 is the first that saves it
19:02:59 <planetmaker> Aali: that's quite late :)
19:03:27 * planetmaker hands a large trout to Rubidium
19:03:49 * Rubidium starts preparing dinner
19:04:25 *** Lakie` is now known as Lakie
19:04:57 <planetmaker> :) not the worst, I guess. Belugas I might actually try it. It's an interesting idea!
19:05:12 <planetmaker> Maybe I'll start with shrimps, though
19:05:40 * planetmaker makes a mental note.
19:07:32 <planetmaker> Belugas: I don't know quiche without cream... :)
19:07:51 <Belugas> my wife can teach you a trick or two...
19:07:59 <Belugas> for the sake of my belly :(
19:08:08 *** Singaporekid has left #openttd
19:08:43 *** Combuster has joined #openttd
19:13:51 *** sigmund has joined #openttd
19:14:49 <CIA-1> OpenTTD: michi_cc * r15655 /trunk/src/articulated_vehicles.cpp: -Codechange: Initialise vehicle vars only after a placement new so possible default constructors don't overwrite the values.
19:22:12 *** Brianetta has joined #openttd
19:27:27 *** energetic is now known as energetic|afk
19:33:28 <Belugas> Thank You Space Expert
19:42:09 <welshdragon> ooh, new Infrastructure Sharing patch
19:42:22 <welshdragon> thank you Swallow
19:49:06 <Yexo> jpm: that's the latest version by celestar
19:49:07 <Aali> it contains the newest official version of cargodest
19:49:29 <Yexo> Aali has continued cargodest, but not there
19:49:47 <Aali> I haven't "continued" cargodest
19:50:00 <Yexo> continued as in updated :)
19:50:18 <jpm> Aali: is you version in cargodest forum thread?
19:51:02 <jpm> Aali: could you breafly tell difference between yours and official versions
19:51:02 <benoid> i am working on a proxy that bans all https pages by content (whenever it matches "cherry" or "bimbo" the page should be blocked and a "meal time later" message must be displayed instead), so i need to add another proxy, for mitming up my https, what mitm proxy can i use?
19:51:23 <Aali> jpm: no difference in functionality, at all
19:51:40 <Aali> well, thats not entirely true, I have fixed some things
19:53:19 <jpm> Aali: I was thinking implementing shared infra to cardodest, yes I know its not easy task, but i have been studying IS patch and maid some simplifications on it...
19:53:55 <Aali> and if you check the old IS thread, you'll find a patch that applies to cargodest
19:54:22 <jpm> yes, but they say its buggy
19:54:40 <Aali> good thing "they" never told me about it
19:55:50 <Aali> ..yes? what happens in multiplayer games?
19:56:14 <jpm> They say its buggy in multiplayer games...
19:56:17 <Belugas> benoid, i guess you're not on the right channel...
19:56:31 <Alberth> benoid: we only transport cargo, not bits
19:57:17 <Aali> jpm: who says that? and when? (I assume you can't tell me what this bug is)
19:57:47 <jpm> And old IS does not provide good way to define rents/payments
19:57:47 <Alberth> benoid: food, water, diamond, coals, etc in our transport game
19:58:29 <jpm> Aali: I can't say because I haven't tried to combine CD and IS,
19:59:01 <jpm> Aali: I would not like to build my patches on buggy combination
20:00:17 <jpm> Aali: Maybe I should give them a try...
20:00:24 <Aali> I'm talking about my IS+cargodest patch here, I know other people have released some buggy shit
20:00:43 <Aali> so if you know anyone who has had problems with that, I would like to get in touch with them
20:01:10 <jpm> Aali: okey, from where I can find you patch?
20:02:34 <Aali> its the last post in the old IS thread
20:02:47 <jpm> okey, thanks I will check it out
20:07:12 <[wito]> the r15642 CD patch works (so far) with r15655
20:08:05 <Aali> you're better off with r15655 ;)
20:09:50 <[wito]> well, it's just 13 revs, tho'
20:10:15 <Aali> it doesn't have a certain nasty memory leak
20:17:29 <Aali> I would not want to configure every single station :/
20:17:54 <jpm> You need only negotiate % with you coplayer
20:18:49 <jpm> Station owner gets now 20% of others road vehicle income on this station
20:19:24 *** NukeBuster has left #openttd
20:19:52 <Yexo> jpm: and what if the station is only used for loading? (so no actual profit is made there)
20:20:13 <Yexo> and I agree with Aali, I wouldn't want to configure the prices for every station seperatly
20:20:16 <jpm> But if you use rent based on capacity or time it is very hard to estimate is cooperation with other players profitable at all...
20:20:50 <RS-SM> we could rent out stations?
20:21:09 <Aali> jpm: the new patch adjusts vehicle profits to include sharing costs
20:21:27 <Aali> so you can easily see if its profitable
20:21:37 <RS-SM> is it possible to make a station split along tracks
20:22:06 <RS-SM> I want to run a subway/monorail shuttle alongside a trans suburban heavy rail set
20:24:24 <jpm> Aali: still adjustment is easier to make if rent is portion of profit/loss
20:25:08 <Aali> well, like Yexo said, what if the profit is made elsewhere?
20:25:24 *** Hirundo has joined #openttd
20:25:59 <Yexo> RS-SM: I'm not sure what you want exactly, do you know about distantant-join-stations?
20:26:04 *** Hirundo is now known as Swallow
20:26:32 <Aali> distantant-join? is that a new feature? :P
20:27:13 <RS-SM> The arrangment is there is a a large 4 tracked heavy electrified tr..
20:27:34 <RS-SM> I assume you need a nightly?
20:27:48 <Aali> you can always stationwalk
20:28:21 *** murr4y_ has joined #openttd
20:28:23 <jpm> Aali: Loading only is problem, you need to negotiate about that too
20:28:28 <RS-SM> I can now actually help my overburdened river crossings
20:28:31 <Yexo> delete the track, build the station so it's on both sides of the track, remove the middle part only
20:28:52 <Yexo> jpm: now what if I use your tracks, but my own stations?
20:28:53 <RS-SM> since I have thousands of people boarding local trains just to go to one station
20:29:11 *** free_kill has joined #openttd
20:29:38 <jpm> Yexo: you are not allowed to use my tracks without permission
20:30:03 <[wito]> Distant-join Stations was the sole reason I went thru the trouble of getting a recent trunk version with cargodest
20:30:05 <Yexo> jpm: that wasn't the point
20:30:11 <[wito]> well, that and cargodest, of course
20:30:58 <jpm> Yexo: Usually we have negotiated routes before hand and that is reason why rent have to be easily estimated
20:31:19 <RS-SM> gentlemen, what custom rail sets do you use, by the way
20:31:45 * Yexo doesn't play that much, and if I play it's mostly online (so whatever rail set the server is using)
20:31:53 <jpm> Yexo: usually if you want to use my tracks you have to use at least on of my stations
20:32:22 <Yexo> jpm: that may be true for the way you want to play, but please think about how other might want to play, and if that works too
20:33:06 <Aali> RS-SM: 2cc, japset or tropic refurbishment set
20:33:28 <RS-SM> I'm mostly an American/Japan combined for rails. 2cc for the locals and the german busses
20:33:31 <jpm> Yexo: Of course I want to know what you think about my idea but let me explain it first ;)
20:33:43 <RS-SM> they are cheap and high capacity for the giant cities
20:33:48 <[wito]> RS-SM: 2cc, NARS, Norwegian, JPset
20:33:57 <Yexo> jpm: you can better explain it to either Aali or Swallow, as they are working on IS
20:34:07 <RS-SM> How are they, cheap or expensive?
20:34:41 <[wito]> RS-SM: expensive, I guess
20:34:42 <jpm> Yexo: Why you asked if you didn't want answer? :)
20:35:04 <RS-SM> ah, I tend to be cheap with my train sets, why I love the FP40
20:35:15 <RS-SM> no cost, it can make money anywhere
20:35:25 <Yexo> of course I'd like an answer, I was just pointing out that convincing me of your idea doesn't really help getting it in IS currently
20:36:44 <jpm> Yeah, I know that our way to play the game is quite different...
20:36:54 <RS-SM> how do you play, might I ask
20:38:20 <Belugas> with a mouse, a screen, a computer and a keyboard :)
20:38:29 <jpm> Once a week, usually sunday night, 3-6 players all good frends of mine
20:38:34 <planetmaker> Oh, I play w/o mouse, Belugas :)
20:38:52 <Belugas> argh... a console fanatic!
20:38:59 <planetmaker> no... touchpad :)
20:39:41 *** NukeBuster has joined #openttd
20:40:09 <Yexo> that little animal a cat likes to eat ;)
20:40:46 <Prof_Frink> I use a moose. Far more interesting.
20:42:20 <jpm> Have have made economy patches to make game play more challenging, bank to loan money from player to player...
20:44:50 *** Shadow_Panther has joined #openttd
20:49:56 *** Arthur_Pallas has joined #openttd
20:50:53 *** free_kill is now known as pavel1269
20:51:13 *** Arthur_Pallas is now known as athanasios
21:15:44 <energetic|afk> jpm: have you checked out alberth's nested windows?
21:15:50 <energetic|afk> (nested widgets)
21:16:04 *** energetic|afk is now known as energetic
21:27:55 *** lobster has joined #openttd
21:28:04 *** NukeBuster has joined #openttd
21:30:33 *** Combuster has joined #openttd
21:33:18 <CIA-1> OpenTTD: frosch * r15656 /trunk/src/settings.cpp: -Fix: Changing dynamic_engines also requires reloading newgrfs as well as resetting the OverrideManager.
21:43:01 *** NightKhaos has joined #openttd
21:50:51 *** stillunknown has joined #openttd
21:55:30 <CIA-1> OpenTTD: rubidium * r15657 /trunk/src/fios.cpp: -Fix [FS#2716]: undeterministic file sorting when the date is equal for all files
22:00:28 <welshdragon> is improved timetable management in trunk?
22:01:04 <Aali> improved timetable management is more or less dead at the moment
22:01:35 <welshdragon> it seemed such a good feature coupled with Infrastructure sharing
22:02:01 <Rubidium> it's following cargodest
22:02:19 <planetmaker> he... good start then abandoned by author?
22:02:23 <[wito]> all we need something that's EA or AE
22:02:31 <[wito]> and we'll have one big chunk: DISC TEAM!
22:02:49 <planetmaker> Are you alright, [wito] ?
22:02:56 <Aali> even ITiM breaks down eventually, it's only marginally less useless than trunk timetables
22:03:09 <Aali> they just can't handle crowded networks
22:03:33 <Aali> excellent for feeder services though
22:04:31 <planetmaker> seemed a bit out-of context to me, but might just be me, being tired, [wito] :)
22:04:44 <welshdragon> it would be interesting if you could have a command 'wait for train/vehicle x to arrive at station y'
22:05:17 <[wito]> planetmaker: I'm talking about the ultimate OpenTTD party pack
22:05:23 <SmatZ> welshdragon: 'and wait until it unloads, and maybe a little more'
22:05:38 <planetmaker> [wito]: also called wwottdgd/3 :P
22:05:57 <planetmaker> anyway... good night for now :)
22:06:05 <[wito]> Infrastructure Sharing + CargoDest + Timetable Management
22:06:49 <welshdragon> SmatZ: no: go to station a: wait for train 1 to arrive at station b: load
22:07:12 <welshdragon> then they both depart virtually same time
22:09:30 <Prof_Frink> Just thought you'd like to know... You just lost the game.
22:10:15 * welshdragon just lost the game too. b*****d
22:11:20 <Prof_Frink> What the devil are you on about, old chap?
22:12:18 <welshdragon> petern however, is
22:13:10 * TrueBrain pushed @kick at the top of the stack
22:14:25 <petern> # we built this city on rock and roll
22:15:00 <CIA-1> OpenTTD: yexo * r15658 /trunk/src/ai/api/ai_abstractlist.cpp: -Fix [NoAI]: Rewrite AIAbstractList::Valuate to make it more readable and fix a crash if no parameters are given to that function.
22:15:07 <Prof_Frink> Rock is good for foundations, but are bread products really suitable?
22:16:32 *** Dred_furst` has joined #openttd
22:21:42 <goodger> Prof_Frink: dwarf bread?
22:23:28 *** racetrack has joined #openttd
22:24:18 <petern> is there a difference between dwarf bread and rock?
22:24:30 <FauxFaux> Rocks are nowhere near as tasty.
22:24:44 <petern> otherwise the dwarves made the trolls...
22:25:43 <Prof_Frink> Dwarf bread is slightly harder.
22:28:53 <petern> and trolls are well 'ard
22:28:59 *** Combuster is now known as [sleep]buster
22:29:27 <goodger> I believe dwarf bread is baked?
22:31:02 *** Dred_furst has joined #openttd
22:42:50 <TrueBrain> I hope it pays money
22:45:43 *** Combuster has joined #openttd
22:51:38 *** Combuster is now known as [sleep]buster
23:08:45 <CIA-1> OpenTTD: yexo * r15659 /trunk/src/3rdparty/squirrel/squirrel/sqstate.cpp: -Fix [Squirrel]: The garbage collection would sometimes loop (2^32 - small_value) times instead of only small_value times.
23:11:52 *** Yeggstry is now known as Yeggzzz
23:18:02 *** KritiK_ has joined #openttd
23:23:57 *** KritiK_ is now known as KritiK
23:27:45 *** Combuster has joined #openttd
23:27:49 <CIA-1> OpenTTD: rubidium * r15660 /trunk/ (5 files in 3 dirs): -Prepare: for 0.7.0-beta2 (ofcourse)
23:27:52 *** Combuster is now known as [sleep]buster
23:28:09 <Aali> is it really okay to call LoadUnloadVehicle with negative values for *cargo_left?
23:30:40 <Rubidium> yes it's okay and intended that way
23:30:46 <SmatZ> int cap_left = v->cargo_cap - v->cargo.Count();
23:30:48 <SmatZ> if (cap_left > 0) cargo_left[v->cargo_type] -= cap_left;
23:30:53 <SmatZ> if you have for example in mind this
23:31:00 <SmatZ> it happens when you change GRF config
23:31:10 <SmatZ> or when you load TTD game modified by TTDAlter
23:31:41 <CIA-1> OpenTTD: rubidium * r15661 /tags/0.7.0-beta2/ (5 files in 3 dirs): -Release: 0.7.0-beta2
23:31:42 <Aali> err, no, it happens alot in a savegame from r15591, when I'm not doing anything
23:32:39 <Aali> cargo_left is an array in disguise?
23:32:51 <SmatZ> of course it's an array
23:33:06 <Aali> not very clear from the function declaration
23:33:28 <SmatZ> int *data is imo better readable than int data[]
23:33:37 <SmatZ> wrt for example sizeof :-p
23:34:12 <Aali> anyway, thanks for your time, I was a bit of an idiot and didn't read the code
23:34:13 <SmatZ> (AcceptedCargo is an array with ugly results when sizeof is used ;)
23:34:29 <SmatZ> you're not idiot for asking ;)
23:41:44 *** DephNet[Paul] has joined #openttd
23:44:13 *** Belugas_Gone has joined #openttd
23:44:13 *** ChanServ sets mode: +o Belugas_Gone
23:46:18 *** DephNet[Paul] has joined #openttd
23:46:18 *** Ridayah_ has joined #openttd
23:47:30 *** HansAffe has joined #openttd
23:49:19 *** Shadow_Panther has quit IRC
23:50:03 *** DephNet[Paul] has joined #openttd
23:50:20 <taisteluorava> is 0.7.0 beta 2 released already?
23:50:57 <Rubidium> depends on what you call released
23:56:54 <NukeBuster> Is a tag enough to be released?
continue to next day ⏵
