Times are UTC Toggle Colours
00:02:43 *** fmauneko [~fmauneko@134.227.101-84.rev.gaoland.net] has quit [Ping timeout: 480 seconds] 00:12:20 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has quit [Remote host closed the connection] 00:12:42 *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Quit: Leaving.] 00:13:30 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd 00:16:16 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ] 00:17:07 *** Devroush [~dennis@94-225-67-91.access.telenet.be] has quit [] 00:22:49 <TruePika> How unoptimized is the original pathfinder when used with ships? 00:23:24 <TruePika> I have 2 ships, a few planes, and who knows how many trains and road vehicals, and my system is starting to lag 00:23:39 <TruePika> Total vehical count being at least 120 00:24:58 <TruePika> Actual counts 90 trains, 24 RVs, 2 ships, 5 aircraft; all pathfinders are set to the reccomended settings 00:25:17 <TruePika> And it seems the system is starting to lag 00:26:10 <TruePika> I usually use larger train counts, as well as RV counts and aircraft counts, and the system doesn't lag AFAIKO 00:46:34 *** Chillosophy [~fu@82-170-139-109.ip.telfort.nl] has quit [] 00:52:55 *** KritiK [~Maxim@95-25-196-145.broadband.corbina.ru] has quit [Quit: Leaving] 01:06:26 <Eddi|zuHause> TruePika: simple test: stop all ships/trains/rv/aircraft from the ship/train/rv/aircraft list, and see if it still lags 01:10:35 <TruePika> Okay... 01:11:05 <TruePika> Lol, just stopped all trains and the network came to a halt 01:12:48 <TruePika> Nope, not laggy (and a couple of airplanes are still in the air - I told them to go to depots) 01:13:06 * TruePika gets only ships @ those airplanes going 01:13:09 <TruePika> *& 01:14:19 <TruePika> Yup, it looks like the ship PF is the source of the problem 01:14:37 *** Eddi|zuHause2 [~johekr@p54B7560A.dip.t-dialin.net] has joined #openttd 01:15:25 <TruePika> Eddi|zuHause2: In case you ping timeout'd, I confirmed that it is the ship PF 01:15:41 <TruePika> And I confirmed that it is set to the original 01:16:05 <TruePika> The route isn't very far; less than 50 tiles IIRC 01:16:46 <TruePika> Yup, total width of route is about 45 tiles 01:17:22 <TruePika> And it is partially 'waypointed' in the way of stations along that 45 tile route 01:17:30 *** Eddi|zuHause [~johekr@p54B75286.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 01:17:40 <TruePika> Any thoughts? 01:18:46 <TruePika> Lol, just re-started the trains: 01:19:03 <TruePika> Train 62's profit last year was - 01:22:26 * TruePika thinks that some window in OTTD should be able to give a value of how much lag there is at the time 01:38:25 *** Progman_ [~progman@p57A1A58E.dip.t-dialin.net] has joined #openttd 01:45:48 *** Progman [~progman@p57A1A787.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 01:46:00 *** Progman_ is now known as Progman 01:53:10 *** Progman [~progman@p57A1A58E.dip.t-dialin.net] has quit [Remote host closed the connection] 02:02:55 <TruePika> Great, now I'm getting all sorts of lag without any vehicals going 02:11:27 <TruePika> For some reason, my ssh daemon is nearing the top for CPU usage, I'm checking DenyHosts... 02:12:00 <TruePika> O_o it was never properly set up 02:16:56 *** thvdburgt [~thvdburgt@banning.xs4all.nl] has joined #openttd 02:23:19 <TruePika> All this time, I thought DENYHOSTS was working properly 02:23:59 <TruePika> Well, that should help with SOME of the lag 02:25:00 *** rhaeder [~quix0r@188.109.242.232] has joined #openttd 02:30:55 *** rhaeder1 [~quix0r@dslb-094-220-142-049.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds] 02:33:17 *** ajmiles [~aj@78-86-188-187.zone2.bethere.co.uk] has quit [Read error: Connection reset by peer] 02:34:53 <TruePika> How long in real time is one day supposed to be if there is no lag? It might just be graphical lag I'm getting 02:35:43 *** thvdburgt [~thvdburgt@banning.xs4all.nl] has quit [Ping timeout: 480 seconds] 02:35:56 <TruePika> ^^ I don't think that's the answer :) 02:38:31 <TruePika> Found it, 2+2/9 seconds 02:39:32 <TruePika> Lol I actually can barely tell if I'm lagging or not when using that number 02:39:57 <TruePika> gtg 03:17:40 *** lugo [~lugo@mgdb-4db8db7e.pool.mediaWays.net] has quit [Remote host closed the connection] 04:26:33 <TruePika> ...I'm back and no conversation went on??? 04:29:14 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 04:33:20 <TruePika> It looks like all of the tasks for 1.0.4 have been completed on the FS 04:33:55 <TruePika> I added another item onto it, one which should be easy to impliment 04:39:31 *** glx [glx@2a01:e35:2f59:c7c0:45b5:ca80:6913:a057] has quit [Quit: bye] 04:56:02 *** Eddi|zuHause2 [~johekr@p54B7560A.dip.t-dialin.net] has quit [Remote host closed the connection] 04:56:21 *** Eddi|zuHause2 [~johekr@p54B77E46.dip.t-dialin.net] has joined #openttd 05:36:43 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has quit [Quit: Leaving] 05:36:53 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds] 05:37:08 *** George [~George@212.113.107.39] has quit [Read error: Connection reset by peer] 05:45:24 *** George [~George@212.113.107.39] has joined #openttd 06:09:43 *** KouDy [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has joined #openttd 06:23:09 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe34dc00-202.dhcp.inet.fi] has joined #openttd 06:28:28 <TruePika> Well, it's 11:30 here, night 06:28:36 *** TruePika [~chris@cpe-67-49-42-88.socal.res.rr.com] has quit [Quit: night] 06:37:45 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has joined #openttd 06:46:06 *** Zuu [Leif@c-cef5e655.510-8-64736c10.cust.bredbandsbolaget.se] has joined #openttd 07:16:13 * andythenorth ponders 07:23:34 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 07:26:51 *** tokai|mdlx [~tokai@port-92-195-1-173.dynamic.qsc.de] has quit [Quit: c('~' )o] 07:27:57 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd 07:28:49 <Terkhen> good morning 07:36:10 <Wolf01> morning 07:49:10 *** Alberth [~hat@82.95.164.127] has joined #openttd 07:52:20 <VVG> morning 07:52:25 <Alberth> hello 07:53:11 <VVG> vc++ users, how do i check all files in a project for incosistent line endings? 07:53:29 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Read error: Connection reset by peer] 07:53:40 <VVG> it's a paing to check them one by one after every failed attempt of tortoise svn to create a patch 07:53:55 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 07:54:13 <Alberth> isn't it simply the file that tortoise complains about? 07:54:36 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Read error: Connection reset by peer] 07:55:02 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 07:55:13 <VVG> it stops after first file it encounters 07:55:41 <VVG> so atm it's create a patch, get to know on which file tortoise failed 1st, go fix it, repeat 07:56:16 <Rubidium> MSVC generally doesn't change line endings 07:56:32 <Rubidium> or at least I haven't heard anyone complaining about it 07:56:43 <VVG> well, then this is not a general case here :) 07:57:16 <Rubidium> I'd just run unix2dos over all (source) files 07:57:45 <VVG> msvc, on some file reloading, popups a dialog "file contains incosistent line endings", with a choice to fix them. 07:57:59 <VVG> of course, those are files i have edited 07:58:15 <VVG> but then again, i edited them in msvc 07:58:18 <Rubidium> one the files that were changed in my patch? 07:58:25 <Rubidium> s/one/on/ 07:58:30 <Alberth> so the list of modified files seems like a good candidate 07:59:05 <VVG> hm, i didn't apply your patch directly, but copypasted the parts to where needed 07:59:26 <Rubidium> so you copy-pasted unix newlines 07:59:28 <VVG> may be this is due to copypasting from some other source but msvc? 07:59:31 *** keoz [~keikoz@pha75-8-82-230-2-115.fbx.proxad.net] has joined #openttd 07:59:33 <VVG> ahha 07:59:43 <Alberth> yay for smart copy/paste handling 08:05:21 <Zuu> I usually do copy pasting from patches in vim where you see inconsintent new-line characters. 08:06:05 <Zuu> Or I can just do a s/\r//g on the patch file before copying code from it. 08:06:38 <Rubidium> I just found out (a day ago) that my editor's remove trailing spaces removes '\r's as well 08:07:30 <Zuu> hmm, editor support for removing trailing spaces sounds like a good idea. 08:08:10 <Zuu> Though, making a regex to detect them is not hard. You just have to remember to do it. 08:09:14 <Terkhen> remembering to run it is the hard part, yes :) 08:14:37 *** Cybertinus [~Cybertinu@a82-95-167-159.adsl.xs4all.nl] has joined #openttd 08:21:22 <Alberth> I have vim highlighting TAB and trailing whitespace 08:23:38 <Terkhen> I should search for similar features in notepad++ 08:32:11 *** De_Ghosty [~s@206-248-186-123.dsl.teksavvy.com] has joined #openttd 08:41:03 *** theholyduck [~holyduck@77.106.158.238] has quit [Read error: Connection reset by peer] 08:49:12 *** Progman [~progman@p57A1A58E.dip.t-dialin.net] has joined #openttd 08:52:42 <VVG> asd 08:52:51 <VVG> asd /* Unfortunately, SetDate() may be called when _date_fract is not initialized */ <-- There is this comment line from old itim. Is this still true? 08:57:05 <Alberth> in general, don't trust comments, whether they hold should be verified by studying the code 08:58:55 <Alberth> about this one, somebody wrote that as a warning, so either assume it is still tha case (ie assume the worst case), or find the code that invalidates that claim 08:59:54 * VVG went exploring the code 09:00:41 <Alberth> oh, and a third option is of course to fix the code so it will not happen 09:06:04 *** DDR [~DDR@d99-199-12-91.bchsia.telus.net] has quit [Ping timeout: 480 seconds] 09:07:47 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has quit [Remote host closed the connection] 09:09:10 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has joined #openttd 09:18:24 <CIA-2> OpenTTD: rubidium * r20591 /trunk/src/ (7 files in 2 dirs): -Codechange: make sure _date_fract is set when SetDate is called. Some places wouldn't reset _date_fract correctly at all 09:18:29 <trebuchet> or remove the comment if the code is found to invalidate the claim 09:18:30 <trebuchet> :? 09:20:19 <Alberth> that would be a logical next step. 09:22:08 <CIA-2> OpenTTD: rubidium * r20592 /trunk/src/ (date.cpp saveload/afterload.cpp): -Fix (r2041): no (proper) savegame conversion was done when _date_fract got a new value range 09:27:55 <VVG> that's some great commits! 09:32:44 <Rubidium> yeah, I'm great at breaking patches 09:34:33 <VVG> i really meant it 09:35:11 <Rubidium> so do I, because depending on the implementation I might've broken the daylength patches 09:35:23 <SpComb> :( 09:35:50 <VVG> oh 09:36:43 <VVG> btw, what's the range some of the daylength patches set length of day in ticks? 09:37:37 <Hirundo> n*DAY_TICKS 09:38:50 <VVG> could have guessed as much 09:42:34 <SpComb> some mad people use up to 64 * DAY_TICKS 09:43:46 <Rubidium> @calc 2**12 / 74 09:43:46 <DorpsGek> Rubidium: 55.3513513514 09:44:19 <Rubidium> that ain't going to work with the timetable stuff VVG is writing 09:44:59 <VVG> :( 09:45:17 <Rubidium> 55 is the maximum 09:45:27 <Rubidium> unless you get really creative 09:45:33 <Rubidium> @calc 2**31 / 366 09:45:34 <DorpsGek> Rubidium: 5867441.6612 09:46:16 <Rubidium> @calc 2**44 / 5000000 / 366 / 74 09:46:16 <DorpsGek> Rubidium: 129.908329969 09:46:28 <Rubidium> ooh... that could work 09:47:00 <VVG> what's that? 09:47:35 *** Sacro [~ben@cpc2-mfld9-0-0-cust880.mfld.cable.virginmedia.com] has joined #openttd 09:48:52 <Rubidium> 2 to the power of (number of bits not used for the vehicle id) divided by the number of years a game has at most divided by the number of days a year (upper bound) divided by the number of ticks a normal day has 09:49:05 <Rubidium> and that returns the daylength factor that could be "hacked" in 09:50:15 <Rubidium> @calc 1826212865 / 5000000 09:50:15 <DorpsGek> Rubidium: 365.242573 09:50:28 <Rubidium> @calc 2**44 / 1826212865 / 74 09:50:28 <DorpsGek> Rubidium: 130.177729223 09:50:32 <VVG> not following you here :( 09:50:35 <Rubidium> oh, even 130 :) 09:50:43 <planetmaker> !calc !pi*1e7 / 365 09:50:50 <planetmaker> @calc !pi*1e7 / 365 09:50:50 <DorpsGek> planetmaker: Error: invalid syntax (<string>, line 1) 09:50:53 <planetmaker> hm 09:51:07 <planetmaker> @calc pi*1e7 / 365 09:51:07 <DorpsGek> planetmaker: Error: invalid syntax (<string>, line 1) 09:51:10 <Rubidium> VVG: that's probably good :) 09:51:16 <planetmaker> @calc pi*10**7 / 365 09:51:16 <VVG> ok :) 09:51:17 <DorpsGek> planetmaker: 86071.0316052 09:51:50 <planetmaker> @calc pi*10**7 / 365.242573 / 24 / 3600 09:51:50 <DorpsGek> planetmaker: 0.995530881971 09:51:53 <VVG> with latest commints, calculating virtual time right in setdate works with a new game and a one save of mine 09:53:32 <Rubidium> for what it's worth, the 1826212865 is MAX_DAY in OpenTTD, i.e. the date of 31st of December 5000000 09:54:49 *** Eddi|zuHause2 is now known as Eddi|zuHause 09:55:06 <VVG> Currently, i'm limited by int64 at calculating _date * DAY_TICKS * vsecs_per_tick 09:57:06 <Rubidium> oh, for that you'll still have roughly 2**20 bits free, i.e. whenever vsecs_per_tick gets close to 1 million you might get into trouble 09:57:09 *** frosch123 [~frosch@frnk-590fc895.pool.mediaWays.net] has joined #openttd 09:57:59 <VVG> well, it's day_ticks that might increase :) 09:58:04 <Rubidium> although arguably vsecs_per_tick probably remains somewhere in the neighbourhood of 1..5; even 256 would be stretching it very far 09:58:21 <VVG> even with 4 it goes by quite fast 09:59:14 <VVG> when i tried to timetable, on a big map on a small route my local train fit in 365 cycle just by. 09:59:45 <Rubidium> VVG: I just "shown you" that 130 is the maximum day length factor that can be accomplished with the current network protocol 10:00:23 <Rubidium> which leaves the 20 bits used for the vehicle id in CmdSetTimetableStart for the vsecs_per_tick 10:00:24 <VVG> i take this statement as is, because i don't get what you showed :) 10:00:41 <VVG> err, 20 bits? 10:01:15 <VVG> it's int32 right now and 20 bits are used for vehid, that leaves 12 free bits 10:01:56 <Rubidium> yes, those 12 bits are used for the ticks within a given date 10:02:37 <Rubidium> the vsecs_per_tick is done (much) later 10:03:21 <Rubidium> it isn't used in the protocol at all 10:03:49 <VVG> i pass offset as ticks right now, that limits it to 4095 10:04:33 <VVG> not sure how vsecs factor in here 10:05:31 <Rubidium> VVG: it doesn't, which is why the 20 bits used here for VehicleID are essentially "free" after (date * DAY_TICKS + _date_fract) 10:06:30 <Rubidium> so if you multiply that number by vsecs_per_tick you *can* multiply it by a vsecs_per_ticks up to 2**20 without causing any (overflow) problems 10:06:52 <VVG> i don't get it 10:08:32 *** KenjiE20 [~KenjiE20@92.19.165.204] has joined #openttd 10:10:52 <Rubidium> then just don't bother about the daylength patch. It'll work fine 10:11:13 <trebuchet> How do I get myself to become addicted to OpenTTD 10:14:10 <trebuchet> I'm under house arrest for a year and they wont allow internet. 10:16:34 <Rubidium> and thus you're asking people on the internet for advice? 10:16:42 <trebuchet> I have a month. 10:19:26 <VVG> what can be done about timetable being, well, too precise? 10:20:00 <Rubidium> how can the timetable be too precise? 10:20:42 <Rubidium> if you want to show seconds, you want such precision in the timetable as well I'd reckon. 10:21:04 <Rubidium> if you don't want them, then minute granularity is good enough (and you can only enter stuff in minutes anyway) 10:22:09 *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd 10:25:56 <VVG> they fluctuate even when vehicle is staying. 10:26:36 <Rubidium> that smells like a bug 10:26:42 <VVG> if i move timetable window they fluctuate too :) 10:27:15 <Rubidium> that definitely smells like a logic bug 10:29:06 <avdg> hmm⊠does openttd windows have minimum sizes? 10:29:21 <planetmaker> yes 10:29:23 <avdg> I don't see 1 on the osx binary and it creates crashes 10:29:40 <planetmaker> or do you mean the global window? 10:29:44 <avdg> yeah 10:29:47 <avdg> global window 10:29:50 <planetmaker> that I don't know 10:29:53 <VVG> SetDParam(param1, STR_JUST_TIME); 10:29:53 <VVG> SetDParam(param2, (_virtual_time + TicksToTime(ticks)) % SECONDS_PER_REAL_DAY ); 10:30:00 <avdg> I'll post the bug on the tracker 10:30:02 <VVG> that's what i have 10:30:47 <planetmaker> ho. Indeed 10:30:54 <VVG> inline Time TicksToTime(Ticks ticks) { return ticks * _settings_client.gui.virtual_seconds_per_tick; } and that 10:31:02 <planetmaker> I don't call that window size usable anymore, though ;-) 10:31:18 <planetmaker> what was it? like... 10 pixels high? 10:32:45 <Rubidium> it doesn't crash with SDL regardless of how small I make it although SDL (or my WM) limits it to at least 1 or 2 pixels high and a dozen or so wide 10:33:09 <VVG> i don't see where a fault can be :( 10:33:22 <planetmaker> Message: Assertion failed at line 153 of /Users/ingo/ottd/trunk/src/core/math_func.hpp: min <= max <-- that's what happens, Rubidium 10:33:45 <planetmaker> let's get a backtrace 10:34:11 <Rubidium> find the clamps in the OSX gui code and one of those will be it 10:34:41 <planetmaker> yeha 10:34:51 <avdg> does it work on other os? 10:35:00 <Rubidium> it doesn't crash on Windows either 10:35:24 <Rubidium> can't be bothered to check Allegro, but that being mostly a copy of SDL it's unlikely to crash either 10:36:06 <Alberth> VVG: what is 'param1' and 'param2'? usually those are constants 10:37:35 <avdg> ok, report added 10:37:56 <VVG> static void SetArrivalDepartParams(int param1, int param2, Ticks ticks) from here 10:40:14 <Rubidium> planetmaker/avdg: might it be that your title bar isn't 22 pixels high? 10:40:19 <avdg> I think the best solution is to add a minimum size, I wasn't able to resize the window again when it was on his smallest possible size 10:40:34 <planetmaker> that may well be. It's smaller afaik 10:40:36 <avdg> can be 10:40:45 <Rubidium> there *is* a minimum size of 64x64 on all supported platforms 10:41:19 <planetmaker> hm. I count 22 pixels 10:41:59 <planetmaker> well. It crashed only when I made the window less high than half of the toolbar would be 10:42:18 <planetmaker> like 3 or 4 pixels 10:42:24 * Rubidium will just blame 10410 10:42:43 <avdg> http://yfrog.com/ccschermafbeelding2010082p 10:42:54 <avdg> thats how a window looks like 10:44:21 <planetmaker> hm? 10:44:46 <avdg> not minimised :) 10:45:08 <avdg> wait, I'll post such a window too :p 10:45:38 <avdg> hmm 10:45:44 <avdg> no crash yet 10:46:38 <avdg> http://yfrog.com/f1schermafbeelding2010082bp 10:46:48 <avdg> thats how small you can get that window 10:49:03 <Alberth> VVG: check the contents of the string you are printing, there are some explanations of the string system at the development wiki 10:49:24 *** trebuchet [~Trebuchet@69.51.104.87] has quit [Quit: Leaving] 10:52:46 <planetmaker> it's not directly related to the window size: http://pastebin.org/718178 10:53:02 <planetmaker> I now tried one minute to make it bigger again before it crashed 10:53:33 <avdg> it happens the same here 10:53:46 <avdg> on the last try it didn't crash at all 10:57:45 <planetmaker> neither here. With 23 defined as height 10:58:12 <avdg> hmm, so there is no mimimum size on all platforms? 10:58:14 <planetmaker> Which *I think* is correct 10:58:30 <planetmaker> because it's 22 pixels menu bar + 1 pixel window 10:58:36 <planetmaker> I can't get it smaller 10:59:23 *** asnoehu [~thok@cc64025-c.hnglo1.ov.home.nl] has quit [Ping timeout: 480 seconds] 11:00:53 <planetmaker> gah. 11:01:24 <planetmaker> I can't get it to crash again 11:01:34 * avdg tries again 11:02:47 <avdg> :/ 11:02:58 <avdg> my window opens now at his smallest state 11:03:42 <avdg> aha 11:03:44 <avdg> again 11:03:54 <avdg> hmm 11:05:16 <planetmaker> hm... I get an idea: click on something in the overly minimized state 11:05:32 <avdg> now I have a window I can't resize anymore :( 11:05:50 <avdg> maybe 11:05:57 <planetmaker> edit your openttd.cfg. And yes, you can re-size. Just tricky 11:06:04 <avdg> :p 11:07:12 <planetmaker> Better idea: tooltip tries to show. That crashes. 11:07:20 <planetmaker> That is also consistent with the backtrace 11:07:50 <avdg> hmm I can't locate that file :( 11:07:57 <planetmaker> what file? 11:08:05 <avdg> openttd.cfg 11:08:13 <planetmaker> Documents/OpenTTD/openttd.cfg 11:08:28 <avdg> oh, its hidden :p 11:08:32 <planetmaker> ? 11:08:39 <avdg> it had no icon 11:09:11 <VVG> Alberth: not sure what i should check there. STR_JUST_TIME prints ok in another place. 11:09:34 *** Devroush [~dennis@94-225-67-91.access.telenet.be] has joined #openttd 11:09:36 <VVG> http://pastebin.ca/1922586 , there are both original, a bottom, and modified, at top. 11:10:14 <Alberth> ok. 11:10:54 <VVG> you sound like i said something stupid :( 11:11:27 <avdg> hmm I can drag and drop the opening window :p 11:11:29 <avdg> wtf 11:12:08 <avdg> ah nvm 11:12:29 <avdg> seems always possible 11:12:34 <avdg> never knew it 11:14:33 <avdg> pm: I think I know whats the problem, donno what you have 11:14:48 <planetmaker> it fails to show the tooltip 11:14:57 <avdg> tooltip? 11:15:27 <avdg> hmm maybe it isn't osx dependent 11:15:45 <planetmaker> what is the problem in your eyes? 11:15:51 *** KritiK [~Maxim@95-25-213-167.broadband.corbina.ru] has joined #openttd 11:16:00 <avdg> I have moved a windows while the height was smaller then the caption bar 11:16:15 *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has joined #openttd 11:17:11 <avdg> yep 11:17:18 <planetmaker> it's not moving 11:17:18 <avdg> I know how to reproduce it 11:17:23 <avdg> doubletab 11:17:25 <planetmaker> it's triggering the tooltip showing 11:17:36 <avdg> not here 11:17:39 <avdg> I think 11:17:46 <planetmaker> which you trigger, if you're in the vicinity of the main menu 11:17:59 <Alberth> VVG: no, I just don't know it either, and I wanted you to know I read your message 11:18:29 <avdg> the bug only occers when the window is smaller then the caption bar and you try to move it 11:18:49 <avdg> A theory that I have is that the captionbar can not be lower then 0 11:19:11 <avdg> but because it doesn't fit, it has to go lower then 0 somehow 11:19:40 <planetmaker> yes. It's the wrong call of clamp 11:20:03 <Alberth> the program goes at length to make sure the caption bar stays visible, otherwise you cannot move the window any more 11:20:48 <planetmaker> yes, but clamp is called like clamp(value, 5, 3) 11:20:58 <avdg> brb, food 11:21:20 <planetmaker> patch incoming 11:22:14 *** ajmiles [~aj@78-86-188-187.zone2.bethere.co.uk] has joined #openttd 11:24:46 <planetmaker> http://bugs.openttd.org/task/4066 <-- there 11:25:17 <planetmaker> Alberth: you can probably try yourself: make the window height 1 pixel. Then make sure the tooltip is called by hovering over the main menu 11:27:41 <Alberth> Thanks for finding out and for the patch. 11:27:41 <Alberth> Unfortunately, now is bad moment, as I am doing other experiments at this moment. Will look at it later, if one of the other devs doesn't first. 11:28:11 <planetmaker> :-) That's fine 11:28:26 *** LunarWolf [~LunarWolf@age193.neoplus.adsl.tpnet.pl] has joined #openttd 11:28:33 <LunarWolf> HI 11:29:29 <LunarWolf> Is there a fix for signaling? 11:29:52 <VVG> hey 11:29:59 <Alberth> is it broken? 11:30:01 <VVG> what's wrong with signaling? 11:30:26 <LunarWolf> I have a bug that they are facing in the wrong direction and in addition do not work as they should 11:30:53 <planetmaker> LunarWolf: first try without 32bpp 11:31:05 <planetmaker> they might have mixed up things 11:31:28 <planetmaker> without any newgrfs also 11:31:40 <planetmaker> if it then is still broken... then it's a bug 11:31:50 <planetmaker> otherwise it's a newgrf problem or a 32bpp set problem 11:32:10 <planetmaker> that said: it works for me 11:34:14 <VVG> i found the cause! 11:35:25 <LunarWolf> And you can not somehow isolate that game does not alter signaling 8bpp to 32bpp. 11:35:40 <planetmaker> signaling isn't altered. 11:35:44 <planetmaker> But graphics might be wrong 11:36:59 <LunarWolf> Who did it? 11:37:52 <planetmaker> you talk to the correct guys in the 32bpp thread 11:41:23 <planetmaker> but asking "when will this be fixed" won't speed up the process ;-) 11:42:05 <LunarWolf> I wrote in one thread about this, but somehow I do not see an effect, because someone solve this problem. 11:43:28 <planetmaker> people have a life, you know 11:43:31 <LunarWolf> know, encoding is not easy to 11:44:15 <planetmaker> I'm sure they'll address that. But chances to have it addressed in 24h are not the best usually 11:44:52 <LunarWolf> I sit alone and write in C + + program to decode a single game, because the distributor did not even know how to patch do (did, but still the game crashes after a while) 11:46:17 <Alberth> VVG: good! 11:46:30 <LunarWolf> and best of all, do not want them to bring and distribute the additive 11:46:56 *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Read error: Connection reset by peer] 11:47:49 <LunarWolf> even the locations they did wrong (fonts are badly done, or not so what you need) 11:47:49 *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd 11:49:28 <planetmaker> then skip those graphics. The default graphics have little issues 11:53:22 <LunarWolf> in which the file is a signaling? 11:55:02 <VVG> http://pastebin.ca/1922600 i have that piecie of code, in timetable_gui.cpp This is to parse a HH:MM:SS string and to convert it later to seconds. Does this look ok? It does what it is supposed to, but i wonder if there are better ways. 11:55:35 <LunarWolf> I may be able to repair or isolate. 11:59:03 <Alberth> VVG: It needs range checking, I think. Also, I'd write it by manipulating characters, but that may be just me, I am not a fan of scanf() 11:59:32 <Alberth> return 0 is useful in any way? 12:00:16 <Alberth> why is adding more text at the end bad? 12:02:12 <VVG> well, that piecie of code is from original itim, a tiny bit adjust to parse query string. return 0 there is because i thought it is a proper way, with no basis on anything. about trail characerts, i think that's because it's not supposed to be anything but HH:MM:SS, a HH:MM:SSS kinda wrong there 12:03:56 *** LunarWolf [~LunarWolf@age193.neoplus.adsl.tpnet.pl] has left #openttd [] 12:05:51 <Alberth> Whether 0 is acceptable depends on what the value is used for, 12:06:24 <Alberth> yeah, you don't want "123" as seconds, but "12 " would be ok imho 12:08:36 *** TomyLobo [~foo@port-212-202-171-176.dynamic.qsc.de] has joined #openttd 12:09:20 <VVG> you mean, just the seconds? 12:09:34 <VVG> as in, only one value scanned? 12:11:13 <Alberth> as value for "SS" 12:17:07 <VVG> compiler gives a warning about unsafe use of bool if i try to use 0 < assigned < 4 :( 12:17:52 <frosch123> use IsInsideMM 12:17:55 <VVG> doing it && way 12:18:56 <VVG> is that an ottd internal function? 12:19:37 <VVG> found a definition 12:20:37 <VVG> not really needed in my case, since it's a range of 1-3, that's all. Was just a bit surprised that a < b < c inside an if gets me a warning 12:20:39 *** Cybertinus [~Cybertinu@a82-95-167-159.adsl.xs4all.nl] has quit [Remote host closed the connection] 12:21:53 *** Sacro_ [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has joined #openttd 12:24:18 <VVG> it produces something unexpected, when inputing just one value 12:24:36 <Hirundo> a < b < c evaluates to (a < b) < c 12:25:50 <VVG> o_0 12:26:08 *** Zuu [Leif@c-cef5e655.510-8-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds] 12:26:45 <Hirundo> and not (a < b) && (b < c) as you might expect, depending on your expectations 12:27:29 *** Sacro [~ben@cpc2-mfld9-0-0-cust880.mfld.cable.virginmedia.com] has quit [Ping timeout: 480 seconds] 12:27:39 *** glx [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has joined #openttd 12:27:42 *** mode/#openttd [+v glx] by ChanServ 12:28:20 <VVG> no wonder compiler complained :) 12:28:25 *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has joined #openttd 12:30:04 *** Sacro_ [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has quit [Ping timeout: 480 seconds] 12:34:42 <Alberth> only a warning :) 12:35:58 *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd 12:37:26 *** lugo [~lugo@mgdb-4db8ddad.pool.mediaWays.net] has joined #openttd 12:38:20 *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has quit [Ping timeout: 480 seconds] 12:39:29 <VVG> well, as i am no "programer, who decides whether the suspicion is justified", it's kinda scary :) 12:42:52 <VVG> hm. it looks like determing whether there were addition characters doesn't matter, they are just truncated anyway. But just one digit is not enough, it produces some strange results. So if only seconds wanted it has to be 00:00:XX, 00:XX if only minutes, XX:00 if only hours, XX:XX for hours minutes. 12:47:33 *** Brin [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has joined #openttd 12:51:03 <VVG> I noticed the "\ No newline at end of file" while looking through diff. Is this critical, bad habit, or doesn't matter at all? 12:52:08 <avdg> its a standard 12:52:43 <avdg> http://en.wikipedia.org/wiki/Diff 12:53:10 <avdg> look up at the backslash 12:53:38 <frosch123> very old compilers cannot deal with lines not ending in new-line. they might ignore it 12:53:46 *** KouDy [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 12:54:09 <avdg> it normally can't hurt, depending on the coding style 12:54:22 *** KouDy [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has joined #openttd 12:54:48 *** GVV [~sdfkhksd@85.249.0.40] has joined #openttd 12:55:18 <Alberth> VVG: you apparently don't type 'ENTER' after the last line 12:55:30 <Alberth> and the editor doesn't add a newline either 12:55:37 *** VVG [~sdfkhksd@85.249.0.40] has quit [Read error: Connection reset by peer] 12:55:45 <GVV> well, i guessed as much myself :) 12:55:51 *** GVV is now known as VVG 12:56:25 <VVG> does it matter? should i be more carefull in the future? 12:57:30 <Alberth> as frosch123 said, old compilers may have trouble with it 12:57:49 <VVG> sorry, i got dropped didn't see anything after my question 12:58:21 <Alberth> http://irclogs.qmsk.net/channels/openttd/last?count=50 12:59:03 <VVG> very handy, thanks 13:00:35 *** Brin [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 13:15:58 * andythenorth ponders 13:17:01 <andythenorth> can New Objects do anything useful for gameplay? 13:17:42 <andythenorth> or eye candy only? 13:18:25 <VVG> Okay. I want to share with any of you who is interested what i have done here. What would be a good place to upload a diff, that doesn't require registration? 13:19:06 * planetmaker guesses: Eye candy only 13:20:03 <Noldo> what are old objects? 13:21:27 <Hirundo> VVG: http://pastebin.com/ 13:22:17 <avdg> hmm, now I can find the "diff" format on pastebin :p 13:23:05 <andythenorth> so NewObjects don't accept / produce cargo 13:23:31 <andythenorth> can they be built by the map generator? I assume so (lighthouse, transmitter) 13:23:50 <planetmaker> specs indicate, they can. At least in the SE 13:24:08 <planetmaker> map generator depends. Before it generates objects, I'd rather have rivers ;-) 13:24:25 <andythenorth> me too 13:24:51 <andythenorth> but we get what's interesting to person writing code, not what we wish for :D 13:25:13 <VVG> http://pastebin.com/SiNTaGGe there we go 13:25:20 <VVG> wrong syntax selected i think 13:25:43 <andythenorth> NewObjects can be built on water? (prop 10 implies so) 13:26:32 <VVG> in case you wonder where the clock is, it's on click switch with date status bar :) 13:27:17 * andythenorth thinks NewObjects could be used to provide reefs, sandbanks, lightships, lighthouses at sea etc 13:27:34 <andythenorth> in two of those cases, cargo production / acceptance might be valid 13:27:49 *** Fuco [~dota.keys@188.123.106.105] has joined #openttd 13:28:05 <andythenorth> I thought of industries for lightship, lighthouse. It's not the right way to do it though 13:29:20 * andythenorth wonders about a new industry cb: distance to nearest new object of class XXXX 13:34:55 *** welshdragon [~dragon@millsie.net] has left #openttd [Leaving] 13:35:15 <Hirundo> VVG: what text editor do you use? 13:40:03 <VVG> msvc to edit source, tortoise svn diff to copypast the lines from to pastebin 13:43:14 <Hirundo> I ask, because spaces/tabs are sometimes intermixed (e.g. english.txt) this often breaks is someone else uses a different tab width 13:43:24 <Hirundo> s/is/if 13:44:04 <VVG> might be just a mistake on my side, not a text editor :( 13:44:48 <Hirundo> Using a text editor that makes whitespace visible helps 13:45:56 <Hirundo> Such minor issues aside, is it necessary to store the virtual time globally, while it basically carries zero information? 13:46:23 <frosch123> andythenorth: be careful with chickens 13:46:33 <frosch123> some object might want to check for industries nearby 13:47:15 <VVG> it's like date 13:47:24 <planetmaker> [15:28] <andythenorth> I thought of industries for lightship, lighthouse. It's not the right way to do it though <-- what does a light house produce? Increased feel-good factor? ;-) 13:47:29 <andythenorth> nothing 13:47:51 <VVG> ever incrementing, looping around 24h. THere is a clock running using it 13:47:52 <andythenorth> well, just passengers, maybe waste (if that cargo is enabled) 13:47:53 <planetmaker> it accepts tourists then? :-P 13:48:08 <andythenorth> maybe :) 13:48:14 <andythenorth> it's not a good case for an industry 13:48:24 <andythenorth> but is good eye candy 13:48:32 <VVG> in any case, that's how it was in original patch :) 13:50:29 <andythenorth> can new objects have stations built in? 13:50:33 <Hirundo> ShowTimeDropDown feels like code duplication to me 13:52:08 <VVG> it is a duplication 13:52:17 <VVG> err, copying 13:52:30 <VVG> you mean, it can be done one ine place for both windows? 13:53:44 *** Phoenix_the_II [ralph@f234099.upc-f.chello.nl] has joined #openttd 13:53:55 <andythenorth> hmmm 13:53:58 *** Biolunar [Mahdi@blfd-5d822a53.pool.mediaWays.net] has joined #openttd 13:54:06 <andythenorth> Fish seems to be the FIRS money maker cargo in 1870 :o 13:54:33 <planetmaker> Probably it's klipfisk from Kristiansund 13:54:40 <planetmaker> can be shipped everywhere for big $$$ 13:55:09 * andythenorth needs more money 13:55:11 <andythenorth> for more trains 13:55:15 <andythenorth> and ships 13:55:18 <Hirundo> VVG: I was just referring to the fact that hours, minutes and seconds have nearly the same code 13:59:04 <VVG> noted 14:07:30 <Hirundo> I can't really put my finger on it, but the whole patch feels a bit overcomplicated 14:07:52 <planetmaker> hm... our clients crash upon connect to our server :-( 14:08:11 <Hirundo> for example, there are now four different settings regarding the precise look of the timetable clock etc 14:09:40 <Alberth> that sounds like 3 too many :) 14:10:00 <planetmaker> *** set a breakpoint in malloc_error_break to debug <-- where do I find that routine? My grep fails... 14:10:15 * avdg fires up opensuse 14:10:17 <Rubidium> planetmaker: libc? 14:10:24 <planetmaker> meh 14:10:44 <planetmaker> I can't re-compile libc 14:11:39 <Rubidium> if it says you should do so I'd argue that that part of the library has debug symbols compiled in 14:13:05 <Rubidium> planetmaker: 4067? 14:13:14 <planetmaker> you try to tell me something... can you... yes 14:13:17 <Hirundo> You should read the whole of this before adding any advanced setting: http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html 14:13:22 <planetmaker> ... tell me what exactly? 14:13:40 <Rubidium> gdb openttd 14:13:48 <Rubidium> breakpoint malloc_error_break 14:13:50 <Rubidium> run 14:14:00 <planetmaker> ok :-) I didn't know that. Will try 14:14:07 <Rubidium> but if it's 4067, did you download some missing NewGRFs before connecting? 14:14:17 <planetmaker> nope 14:14:39 <planetmaker> I just connected with 'join company' from the lobby, straight after startup 14:15:05 <VVG> i admit, seconds from actual clock can be removed. what about timetables? all four choices for now seem feasable 14:15:10 <Rubidium> as it smells like FS#4055 14:17:26 <Hirundo> the statusbar settings are pretty bogus IMO, the rest can be left as-is 14:19:02 <planetmaker> Rubidium: I used the 'search server' function, though 14:20:22 <planetmaker> Rubidium: backtrace with breakpoint attached to 4055 or 4067? What do you prefer? 14:20:34 <Rubidium> the one you made 14:21:07 <planetmaker> done 14:23:59 <VVG> both of status bar settings? 14:24:22 *** Zuu [Zuu@c-def4e655.510-8-64736c10.cust.bredbandsbolaget.se] has joined #openttd 14:27:03 *** Progman [~progman@p57A1A58E.dip.t-dialin.net] has quit [Remote host closed the connection] 14:35:15 <planetmaker> http://ps.openttdcoop.org/public/save/autosave/autosave254.sav <-- that savegame crashes upon load, Rubidium 14:35:30 <planetmaker> that's the most recent one from the PS 14:46:47 *** JVassie [~James@92.27.149.231] has joined #openttd 14:49:58 *** HerzogDeXtEr [~Flex@88.130.164.46] has joined #openttd 14:49:59 *** HerzogDeXtEr1 [~Flex@88.130.170.66] has quit [Read error: Connection reset by peer] 14:55:39 *** Yexo [~Yexo@ip51cca4b5.adsl-surfen.hetnet.nl] has joined #openttd 15:18:11 * Zuu wonders how far *Ar4er will keep trying to write an AI without basic programming knowledge. 15:20:00 <Alberth> as long as someone tells him what to do, is my guess 15:26:05 *** Yexo [~Yexo@ip51cca4b5.adsl-surfen.hetnet.nl] has quit [Quit: bye] 15:29:03 *** Zuu [Zuu@c-def4e655.510-8-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds] 15:42:08 *** nicfer [~nicfer@190.50.6.241] has quit [Read error: Connection reset by peer] 15:42:11 * Rubidium wonders when someone writes the equivalent of labview for AIs 15:42:24 * roboboy might oneday consider trying to write an AI 15:42:43 * avdg might to give squirel another try 15:44:27 <planetmaker> lol labview for AIs :-) 15:46:58 *** glx_ [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has joined #openttd 15:47:01 *** mode/#openttd [+v glx_] by ChanServ 15:47:04 * roboboy should go to sleep 15:49:52 <Rubidium> planetmaker: now try to envision labview and matlab glued together with java :) 15:50:00 <planetmaker> urgs 15:50:16 <planetmaker> I can imagine nicely labview and matlab glued together. But java... urgs 15:50:50 <planetmaker> shit: http://sine.ni.com/cs/app/doc/p/id/cs-11435 15:51:28 <planetmaker> http://sine.ni.com/nips/cds/view/p/lang/en/nid/209047 <-- and that 15:51:33 <planetmaker> so... that basically exists 15:53:31 *** glx [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has quit [Ping timeout: 480 seconds] 15:56:13 <Alberth> I kind of expected that, at least the LV / ML combination 15:57:17 <planetmaker> yes, the latter exists, I knew that :-) 15:58:02 <planetmaker> or rather: it'd have surprised me a lot, if they offer IDL interface but not ML 15:58:08 <frosch123> the interesting part about labview is, that you can tell advanced users from beginners just by asking them about "shift registers" 15:58:17 <planetmaker> :-) 15:58:20 *** Pixo[hol] [~Pixohol]@p54B4DE4F.dip.t-dialin.net] has joined #openttd 15:58:39 <planetmaker> they can be quite useful indeed 15:58:57 <Rubidium> I'd say: by some clicking 15:59:05 <Pixo[hol]> hello @ all 15:59:14 <planetmaker> moin Pixo[hol] 15:59:23 <Pixo[hol]> ah german? 15:59:43 <frosch123> we do not like germans here 15:59:44 <planetmaker> English only :-P 15:59:57 <Pixo[hol]> :P no problem at all 16:00:02 *** perk11 [~perk11@178.34.165.55] has joined #openttd 16:00:51 <Pixo[hol]> :D ia have a technical problem, and after hours of websearch i cant isolate the problem 16:01:32 <Pixo[hol]> openTTD 1.0.3 x64 on windows 7 dont play any sound since this morning 16:03:05 <planetmaker> sound, music or both? 16:03:09 <Rubidium> do other applications play sound? 16:03:11 <Pixo[hol]> both 16:03:26 <Pixo[hol]> yes all other windows application play sound 16:03:43 <Pixo[hol]> i reinstalled openTTD 16:04:01 <Rubidium> start openttd, in the main menu click on "Game options" 16:04:17 <Pixo[hol]> yes 16:04:20 <Pixo[hol]> i have 16:04:26 <Rubidium> there's an area, almost at the bottom, that says "Base sound sets" 16:04:28 <planetmaker> NoSound and NoMusic as base sets? 16:04:50 <Pixo[hol]> no there are the OpenSFX and OpenMSX 16:04:51 <Rubidium> which set have been chosen, i.e. what does the dropdown directly below "Base sound sets" say? 16:05:33 <planetmaker> Pixo[hol]: if those two are selected, is the output volume also not set to very low? 16:05:39 <Hirundo> Is your application-specific volume set correctly in the windows mixer? 16:05:40 <planetmaker> You can check that (only) ingame 16:06:03 <planetmaker> i.e. start a map and go to the music & sound settings there 16:06:30 <Pixo[hol]> both on may value 16:06:32 <Pixo[hol]> ingame 16:06:45 <Pixo[hol]> the windows volume is normal to 16:06:51 <Pixo[hol]> lika all other applicatins 16:07:34 <Rubidium> how familiar are you with the command prompt? 16:08:16 <Pixo[hol]> the windows one? not really familiar 16:08:44 *** asnoehu [~thok@82.75.115.73] has joined #openttd 16:09:13 <Rubidium> yes, well familiar enough to start OpenTTD from there with -ddriver=1 as parameter? 16:10:04 <Pixo[hol]> yeah 16:10:06 <Pixo[hol]> ;) 16:10:08 <Pixo[hol]> its startet 16:10:38 *** asnoehu is now known as tycoondemon 16:10:56 <Rubidium> and it should have opened a second window with some text on it 16:11:03 <Pixo[hol]> yeah 16:11:16 <Rubidium> what does that say about the sound driver(s)? 16:11:30 <Pixo[hol]> can i c&p here? 16:11:41 <planetmaker> pastebin.org 16:11:42 <Rubidium> you can to pastebin.com 16:13:53 <Pixo[hol]> http://pastebin.com/RYAX630s 16:14:42 <Rubidium> so it all went fine (for x64 standards) 16:15:07 <Pixo[hol]> yeah 16:15:31 <Rubidium> now I'm out of ideas (don't use Windows myself, so I'm not really familiar with new "features") 16:15:47 <Pixo[hol]> hm ok 16:16:00 <Rubidium> although maybe you can check Hirundo's comment about application specific volume settings (never heard of it myself) 16:16:17 <Pixo[hol]> yeah i checked this one 16:16:20 <Pixo[hol]> too 16:16:34 <Pixo[hol]> all applications on normal 16:22:19 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 16:22:27 *** sparr [sparr@c-24-98-228-62.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 16:24:33 *** sparr [sparr@c-24-98-228-62.hsd1.ga.comcast.net] has joined #openttd 16:33:43 <roboboy> I get no music with the same setup as above using either orig_win or openMSX 16:35:28 <roboboy> the Jazz Jukebox shows no music at all except when I open the window to create a programme, then it shows all the tracks 16:38:22 <Rubidium> planetmaker: is the server still running? 16:38:35 <Rubidium> the one with 4067 16:38:54 <Rubidium> or have you killed it already? 16:42:36 <avdg> its still running 16:42:49 <avdg> combuster has already coming up with an evil patch 16:43:00 <avdg> http://dimensionalrift.homelinux.net/combuster/openttd_hackme.diff 16:43:48 *** [com]buster [~marcel@cust-03-55bf402e.adsl.scarlet.nl] has joined #openttd 16:45:06 <Pixo[hol]> ok sound is working, i think its a bug 16:45:23 <Pixo[hol]> or a feature ;) 16:47:48 <Rubidium> avdg: that's just stupid 16:47:51 <CIA-2> OpenTTD: rubidium * r20593 /trunk/src/order_backup.h: 16:47:51 <CIA-2> OpenTTD: -Fix: (rlongago, r20547): long ago the service interval was int16, after which 16:47:51 <CIA-2> OpenTTD: is got converted to Date except in the order backup. Much later I copied the 16:47:51 <CIA-2> OpenTTD: savegame snippets from a vehicle and applied that on the order backup. Presto, 16:47:51 <CIA-2> OpenTTD: reading/writing 32 bits (of Date) into 16 bits of ancient style service 16:47:53 <CIA-2> OpenTTD: interval. That would then "spoil" the name pointer and that eventually crashes 16:47:55 <CIA-2> OpenTTD: OpenTTD as it's likely to be an invalid pointer. 16:48:36 <Terkhen> Pixo[hol] roboboy: music and sound work for me under windows 7 with openttd 1.0.3 x64 16:49:00 <Rubidium> avdg: http://rbijker.net/openttd/pm_stopgap.diff would be multiple times better, although still a hack. The above fix, which forgot to mention FS#4067, is the best fix 16:50:08 <Rubidium> avdg: although there's another server side fix, but that might break player behaviour 16:50:46 <Rubidium> in any case, I suggest that #openttdcoop migrates to r20954+ in two hours 16:51:19 <avdg> k 16:51:37 *** sparr [sparr@c-24-98-228-62.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 16:54:05 * Rubidium wonders how many in here recognise (parts of) http://rbijker.net/openttd/output.aac 16:54:44 *** Sacro [~ben@host86-173-24-44.range86-173.btcentralplus.com] has joined #openttd 16:56:03 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 16:57:21 *** Sacro [~ben@host86-173-24-44.range86-173.btcentralplus.com] has quit [Read error: Connection reset by peer] 16:58:34 *** Yexo [~Yexo@ip51cca4b5.adsl-surfen.hetnet.nl] has joined #openttd 16:59:28 *** Sacro [~ben@212.183.140.102] has joined #openttd 16:59:49 * Rubidium waves in the general direction of Vjenne 17:00:25 *** Sacro [~ben@212.183.140.102] has quit [Read error: Connection reset by peer] 17:00:30 <planetmaker> [18:50] <Rubidium> in any case, I suggest that #openttdcoop migrates to r20954+ in two hours <-- nice :-) 17:00:38 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds] 17:01:23 <Rubidium> oh, one tip: make sure everyone is disconnected before you do the final save (the save you're going to reload into the new nightly) 17:01:44 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 17:02:00 <planetmaker> everyone disconected? What difference does it make? 17:02:30 <Rubidium> planetmaker: the crash cause is the order backup pool. If everyone is disconnected that pool ought to be empty 17:02:41 *** perk11 [~perk11@178.34.165.55] has quit [Read error: Connection reset by peer] 17:03:49 <Eddi|zuHause> good morning everybody. 17:03:58 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 17:04:19 <planetmaker> oh 17:04:32 <Eddi|zuHause> EBacklogTooLong... 17:04:32 <planetmaker> moin Eddi|zuHause 17:04:38 *** perk11 [~perk11@94.233.241.125] has joined #openttd 17:06:44 * frosch123 does not recognise any parts 17:10:50 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 17:13:41 <planetmaker> Rubidium: if we play with the patch for the current version: will we need a no-player save again when we update in two hours? 17:14:11 <Rubidium> planetmaker: probably not 17:19:41 <planetmaker> thank you very much :-) You made a number of players quite happy :-) 17:20:16 *** glx [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has joined #openttd 17:20:19 *** mode/#openttd [+v glx] by ChanServ 17:25:40 *** Pixo[hol] [~Pixohol]@p54B4DE4F.dip.t-dialin.net] has left #openttd [] 17:26:25 *** Progman [~progman@p57A1A58E.dip.t-dialin.net] has joined #openttd 17:26:30 *** glx_ [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has quit [Ping timeout: 480 seconds] 17:30:37 *** asilv [~as@h-62-142-160-55.joensuunelli.fi] has joined #openttd 17:31:50 *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has quit [Ping timeout: 480 seconds] 17:33:42 <avdg> lol http://translate.google.com/translate?js=y&prev=_t&hl=nl&ie=UTF-8&layout=1&eotf=1&u=http://www.computable.nl/artikel/ict_topics/security/3478072/1276896/trojans-veroorzaakten-spaanse-vliegtuigramp.html%3Futm_campaign%3Dtweakers%26utm_source%3Dtweakers%26utm_medium%3Dtweakers&sl=nl&tl=en 17:34:08 <avdg> actually not so funny :/ 17:35:21 <Rubidium> yay for social engineering :( 17:37:37 *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Read error: Connection reset by peer] 17:37:54 *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd 17:44:20 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds] 17:45:48 <CIA-2> OpenTTD: translators * r20594 /trunk/src/lang/ (10 files): (log message trimmed) 17:45:48 <CIA-2> OpenTTD: -Update from WebTranslator v3.0: 17:45:48 <CIA-2> OpenTTD: german - 2 changes by planetmaker 17:45:48 <CIA-2> OpenTTD: icelandic - 19 changes by grjonib 17:45:48 <CIA-2> OpenTTD: italian - 1 changes by lorenzodv 17:45:49 <CIA-2> OpenTTD: polish - 6 changes by xine 17:45:49 <CIA-2> OpenTTD: portuguese - 15 changes by JayCity 17:53:06 *** devilsadvocate_ [~devilsadv@202.3.77.41] has quit [Excess Flood] 17:56:06 *** Vitus [~chatzilla@138.194.wms.cz] has joined #openttd 17:58:26 *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #openttd 17:59:31 *** ProfFrink [~proffrink@5e0a64c8.bb.sky.com] has joined #openttd 18:04:06 *** glx_ [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has joined #openttd 18:04:09 *** mode/#openttd [+v glx_] by ChanServ 18:05:13 *** Prof_Frink [~proffrink@5e0a74b3.bb.sky.com] has quit [Ping timeout: 480 seconds] 18:05:13 *** ProfFrink is now known as Prof_Frink 18:07:12 *** fmauneko [~fmauneko@88.166.241.226] has joined #openttd 18:10:20 *** glx [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has quit [Ping timeout: 480 seconds] 18:11:15 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 18:13:35 *** fmauneko [~fmauneko@88.166.241.226] has quit [Quit: fmauneko] 18:14:10 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 18:15:16 *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Remote host closed the connection] 18:15:35 *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd 18:30:58 *** DDR [~DDR@d99-199-12-91.bchsia.telus.net] has joined #openttd 18:34:31 <andythenorth> planetmaker: I lost your transfer order patch again :( 18:34:43 <andythenorth> can you remind where it is - sorry 18:34:47 <planetmaker> somewhere on flyspray :-) 18:34:56 <andythenorth> thanks 18:35:08 <planetmaker> http://bugs.openttd.org/task/3905 18:35:12 <planetmaker> ^ :-) 18:35:30 * planetmaker has an ever growing dir of patches ;-) 18:35:51 <planetmaker> most of which can meanwhile be considered junk, though 18:36:18 <andythenorth> hmm 18:36:34 <andythenorth> patch fails to apply against 20594 18:37:42 <andythenorth> don't understand why :o 18:38:33 <avdg> hmm 18:38:39 <avdg> no time to upgrade? 18:39:05 <avdg> ow srr wrong channel :p 18:40:14 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 18:40:52 <planetmaker> uhm... andythenorth because there are now 1 million vehicles, not only 64k 18:40:59 <andythenorth> brrr 18:43:05 <Alberth> andythenorth: you don't save cargo fractions, do you? (ie 7ton of wool gets lost without ever producing goods) 18:43:26 <andythenorth> Alberth: it's a ticket :) 18:43:46 <andythenorth> http://dev.openttdcoop.org/issues/1056 18:44:06 <andythenorth> I need to fix that one :) 18:44:32 *** Zuu [~Zuu@c-2df1e655.510-8-64736c10.cust.bredbandsbolaget.se] has joined #openttd 18:44:48 <Alberth> yeah, it makes playing with trucks less fun 18:44:57 *** glx [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has joined #openttd 18:45:00 *** mode/#openttd [+v glx] by ChanServ 18:45:11 *** Sacro [~ben@212.183.140.38] has joined #openttd 18:45:40 <planetmaker> andythenorth: checkout the FS entry again 18:46:06 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 18:46:10 *** devilsadvocate [~devilsadv@202.3.77.41] has joined #openttd 18:46:19 <andythenorth> yay 18:46:32 <andythenorth> that would be a nice one for trunk :o 18:47:26 <Rubidium> I'm still wondering whether Ctrl-Click unload should trigger "Transfer and leave empty" 18:47:50 *** perk11 [~perk11@94.233.241.125] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 18:51:26 *** glx_ [glx@2a01:e35:2f59:c7c0:48e9:1e3f:a5d8:8f7a] has quit [Ping timeout: 480 seconds] 18:51:29 <Vitus> That sounds like good idea, indeed :) 18:51:29 *** Sacro_ [~ben@212.183.140.38] has joined #openttd 18:51:31 <planetmaker> might be a nice idea, Rubidium 18:53:10 <andythenorth> would suit me 18:55:39 *** devilsadvocate [~devilsadv@202.3.77.41] has quit [Ping timeout: 480 seconds] 18:58:53 *** Sacro [~ben@212.183.140.38] has quit [Ping timeout: 480 seconds] 18:58:56 *** devilsadvocate [~devilsadv@202.3.77.41] has joined #openttd 19:01:51 *** Sacro [~ben@212.183.140.38] has joined #openttd 19:05:01 *** Sacro_ [~ben@212.183.140.38] has quit [Ping timeout: 480 seconds] 19:05:25 <avdg> looks like we have another crash :( 19:06:00 <avdg> http://pastebin.com/709tyAL8 19:07:06 *** devilsadvocate [~devilsadv@202.3.77.41] has quit [Ping timeout: 480 seconds] 19:08:15 <planetmaker> wrong os, avdg :-P 19:08:24 <avdg> i know 19:08:30 <avdg> its from giant 19:09:26 <Rubidium> avdg: file a bug report with the crash.dmp and all other related files 19:09:42 <avdg> no relating bug? 19:09:44 <avdg> k 19:10:01 *** Sacro [~ben@212.183.140.38] has quit [Ping timeout: 480 seconds] 19:10:14 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ] 19:10:15 <Rubidium> and that ancient 0.3.[34] savegame you're loading 19:12:04 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe34dc00-202.dhcp.inet.fi] has quit [] 19:12:30 <Rubidium> planetmaker: the 4066 diff fixes your problems? As it won't fix my 4066 crash 19:13:01 <planetmaker> hm. avdg said he could also still crash it 19:13:19 <planetmaker> but from what I tested, it didn't crash here then anymore 19:13:34 <avdg> donno, its better to let him give the word 19:13:36 <Eddi|zuHause> might be two differrent crashes 19:13:42 <Rubidium> so there's a "not high enough" and "not wide enough" crash in there 19:14:17 *** Giant [~Giant@dhcp-077-248-029-049.chello.nl] has joined #openttd 19:14:31 <avdg> ah :) 19:14:37 <Giant> happy now? :P 19:14:41 <avdg> :p 19:16:00 <CIA-2> OpenTTD: frosch * r20595 /trunk/src/vehicle_cmd.cpp: -Fix (r20536)[FS#4068]: Autoreplace needs refitting of wagons in free wagon chains. 19:17:26 <avdg> so giant has a random crash, so he doesn't know the source of it 19:22:39 *** fmauneko [~fmauneko@88.166.241.226] has joined #openttd 19:24:13 <frosch123> 0.3.x savegames are not random 19:24:36 <avdg> cmon giant talk to us 19:24:46 <avdg> :p 19:24:54 <Giant> hmm? 19:25:01 <Giant> then what? 19:25:10 <Giant> you basically named all I know atm haha 19:26:38 <avdg> do you have still problems with the binaries? 19:27:23 <Rubidium> avdg: so he's the guy of the crashlog you pasted? 19:27:28 <avdg> yeah 19:27:54 <Giant> no avdg 19:27:58 <Giant> like I told you 19:28:03 <Giant> it's 100% random crash 19:28:43 *** TruePikachu [~chris@cpe-67-49-42-88.socal.res.rr.com] has joined #openttd 19:28:43 <Giant> doesn't really happen to often when actually playing though 19:28:54 <Giant> mostly at starting the game up 19:28:55 <avdg> no, it shouldn't 19:30:29 <frosch123> ah, so it is the titlegame 19:30:41 <Rubidium> avdg: in that case Giant should post the crash.log, crash.dmp, crash.png, crash.sav etc to bugs.openttd.org 19:30:54 <avdg> I know, he's kinda lazy :p 19:31:02 <Giant> (A) 19:32:31 <Rubidium> avdg, planetmaker: does http://rbijker.net/openttd/fs4066.diff fix (all) the issues? 19:32:53 <avdg> lets see 19:33:34 <Rubidium> avdg: if he's too lazy we can't fix the bug he is triggering 19:34:03 <Giant> lol 19:34:10 <Giant> am already working on it.... 19:34:15 <avdg> aha :) 19:36:14 <Giant> hmm 19:36:20 <Giant> Rubidium: no crash.sav existant 19:36:59 <Rubidium> then attach the savegame you were loading/did load before it crashed (the OpenTTD 0.3.3/0.3.4 one) 19:37:05 <Giant> lol 19:37:11 <Giant> wasn't loading this time 19:37:24 <Giant> was updating/downloading newgrfs this time 19:38:07 <Rubidium> so you've already let OpenTTD overwrite the previous crashlog, the one avdg showed a while ago? 19:38:25 <Giant> no 19:38:30 <Giant> it didn't crash after 19:38:45 <frosch123> Rubidium: isn't the titlegame a 0.3.4 one? 19:39:05 <Rubidium> hmm, good point 19:39:24 <Alberth> not the 1.0 stable 19:39:44 <Rubidium> it's a nightly 19:40:02 <Alberth> then it should be ok :) 19:40:28 <Rubidium> guess the addition of NewGRFs did uhm... fool me 19:40:46 <Giant> ok 19:40:46 <avdg> rubidium: same steps, same error 19:41:16 <Rubidium> avdg: build a debug build, run it in gdb and once it crashes "bt full" and pastebin that 19:41:44 <avdg> hmm never ran a debug build 19:41:57 <Rubidium> ./configure --enable-debug=3 19:41:59 <Rubidium> make run-gdb 19:42:02 <avdg> k :) 19:42:19 <Rubidium> wait a bit for it to compile and start OpenTTD, reproduce issue 19:42:34 <avdg> k 19:42:35 <Rubidium> type "bt full" in the (gdb) prompt 19:43:00 <avdg> as separated program 19:43:41 <avdg> hmm does it matter if the patch is applied or not? 19:43:54 <Rubidium> leave it applied 19:43:57 <avdg> k 19:48:34 <avdg> ok, recorded 19:48:51 <avdg> hmm it says no stack 19:51:12 <Rubidium> huh? 19:51:43 <Rubidium> could you paste the last few lines of the console then? Basically from after the compilation completed 19:53:43 <avdg> http://pastebin.com/Fy5rppWK 19:53:59 <avdg> I've run openttd in an other cli tab 19:54:02 *** LunarWolf [~LunarWolf@age193.neoplus.adsl.tpnet.pl] has joined #openttd 19:54:17 <Giant> http://bugs.openttd.org/task/4069 < - posted the report a bit back btw 19:54:19 <Rubidium> hmm, stupid OSX... 19:54:29 <Rubidium> avdg: type run in that gdb window 19:54:39 <avdg> aha 19:54:56 <Rubidium> make run-gdb is supposed to start OpenTTD when gdb is started, but apparantly there's yet another thing that doesn't work on Mac OS X 19:55:27 <avdg> ok, recorded 19:55:49 <avdg> should I type bt full again? 19:55:53 <Rubidium> yes 19:57:09 *** lobstar [~michielbi@86.89.201.189] has quit [Quit: AS A VAGINA ONCE SAID: <yorick> SOMEONE BAN HIM] 19:58:28 <LunarWolf> hi, trying to find the culprit responsible for the malfunction signaling. 19:58:35 *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing] 19:58:47 <Rubidium> LunarWolf: 32bpp graphics? 19:58:56 <LunarWolf> yep 19:59:04 <avdg> http://pastebin.com/hYdDiyt3 19:59:05 <Rubidium> then (s)he's most likely not here 19:59:15 *** Agame [pipo@sr2.fi] has joined #openttd 19:59:25 <Agame> hi there 19:59:41 <Agame> how many days are there in openttd calendar? 19:59:43 <Rubidium> avdg: hmm, that trace looks way different from what I could reproduce 19:59:53 <avdg> hmm possible other bug 20:00:16 <LunarWolf> but I noticed that when you try to extract the files "BaseSet" something crashes and I have no spirites 20:00:16 <Rubidium> Agame: 1826212865 20:00:19 <planetmaker> Rubidium: the make run-gdb required configure debug=3 or otherwise normally, too? 20:00:26 <Agame> roger 20:00:55 <Rubidium> Agame: but that's the total number of unique days in OpenTTD; generally it's 365 or 366 a year 20:01:17 <Rubidium> planetmaker: make run-gdb doesn't require a particular debuglevel, but... the higher the better the information 20:02:13 <avdg> pm: you're right about the missing sprites, the bugreport is clear as water 20:02:23 * Rubidium wonders why avdg's OpenTTD thinks of dragging windows, or is it that he dragged a window when he made the resolution really low? 20:02:36 <avdg> its smaller then the caption bar 20:02:53 <avdg> then move it, bang! 20:03:05 <avdg> same steps as on the bugreport 20:03:10 <planetmaker> that's particular to your build. doesn't crash for me 20:03:16 <avdg> hmm 20:03:22 <planetmaker> just tried again 20:03:44 <Rubidium> avdg: but then I can't reproduce it because as soon as I release my mouse the window gets forced to the minimum 64x64 pixels 20:03:58 <Rubidium> which is way higher than the few pixels you've got 20:04:08 <Rubidium> and that means that that issue is Mac OS X specific 20:04:53 <planetmaker> hm... draging which window? Main window or an ingame window? 20:05:21 <Rubidium> but to drag a window in OpenTTD you need to release the mouse resizing the window, right? 20:05:23 <avdg> http://yfrog.com/nfschermafbeelding2010082p 20:05:25 <planetmaker> Rubidium: you OpenTTD window gets forced to 64^2 pixels? 20:06:09 *** Agame [pipo@sr2.fi] has quit [Quit: leaving] 20:06:13 <LunarWolf> ! E: \ Game MOD \ OpenTTD \ 32bpp \ Graphics Base Set \ baseset_12-03-10 \ BaseSet.tar: Can not open ogfxe_extra (sprites \ openttdd -> ogfxe_extra) 20:06:20 <planetmaker> avdg: does it still happen, if you update your OpenGFX, that is if the error message doesn't exist anymore? 20:06:28 <avdg> lets see 20:06:54 <glx> LunarWolf: trunk ? 20:06:54 <planetmaker> you'll need to get a nightly download of it 20:07:26 <avdg> its not in the online content 20:07:31 <avdg> oh 20:07:38 <avdg> can you provide me the url then? 20:07:55 <Rubidium> planetmaker: yes, and maybe http://rbijker.net/openttd/maybe_this_works.diff enforces that for you as well 20:08:00 <LunarWolf> so with all the files in the sprites 'baseset_12-03-10' 20:08:26 <planetmaker> oh. Well, my windows were 1px hight, if I wanted. let's see 20:08:54 <avdg> should I leave the other patch too? 20:09:00 <Rubidium> avdg: yep 20:09:02 <avdg> k 20:09:12 <Rubidium> glx: he's using the 32bpp extra zoom thing 20:09:13 <glx> LunarWolf: there use to have openttdd.grf and openttdw.grf, but in recent nightlies there's only openttd.grf 20:10:52 <avdg> error 20:11:15 <LunarWolf> This is a WinRAR archive 20:11:43 <Rubidium> OpenTTD can't open winrar files 20:11:45 <avdg> http://pastebin.com/17u9KaSv 20:12:24 <LunarWolf> PCX unpacked correctly 20:12:38 *** Zuu [~Zuu@c-2df1e655.510-8-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds] 20:13:19 <Rubidium> avdg: new version, same url 20:13:42 <avdg> ? 20:13:59 <Rubidium> new version of the diff, with the same url, for you to try 20:14:06 <Rubidium> might fix your compile error 20:14:28 * Rubidium wonders why he's going on this hack-and-stab approach of fixing OS X specific bugs again... 20:15:03 * avdg is confused 20:16:19 <Rubidium> avdg: arguably you just applied a diff as you got compile errors on the lines that diff changed. I maybe have fixed those compile errors and uploaded a new version of that diff with the same name, i.e. the url remained the same 20:16:38 <avdg> I see no diffrends 20:16:52 <Rubidium> then your browser is stupid in caching the file 20:16:59 <avdg> can be 20:17:12 <Rubidium> anyhow s/max/max<int 20:17:14 <Rubidium> anyhow s/max/max<int>/ 20:17:20 <avdg> ah :) 20:17:24 <avdg> yeah got it 20:18:52 <avdg> hmm have to reapply both patches, before svn and patch complains :p 20:19:54 * avdg isn't happy about freezing terminal 20:20:10 *** Zuu [Zuu@c-2df1e655.510-8-64736c10.cust.bredbandsbolaget.se] has joined #openttd 20:21:21 <planetmaker> window can still be made to 1px height with that patched 20:21:38 <Rubidium> good 20:21:40 <avdg> that patch is osx specific isn't it? 20:21:51 <Rubidium> yes, it's very osx specific 20:22:20 <avdg> ok, I can't drag the window and nothing happens 20:23:24 <avdg> if thats what you've had in mind, then its ok 20:23:34 <LunarWolf> whether it is signaling slump 32bpp graphics, without removing other graphics 20:23:54 <Alberth> avdg: (about terminal freezing) forgot the < or the -i option of patch ? 20:24:01 <avdg> yeah 20:24:03 <avdg> fixed :p 20:24:18 <avdg> it was the < 20:24:35 <Alberth> good programmers type a patch from the keyboard :p 20:24:48 <planetmaker> :-P 20:25:06 <avdg> :p 20:25:13 *** Alberth [~hat@82.95.164.127] has left #openttd [] 20:26:00 <CIA-2> OpenTTD: rubidium * r20596 /trunk/src/misc_gui.cpp: -Fix [FS#4066]: crash when the tooltip is wider than the window is 20:26:59 <avdg> :) 20:31:59 <avdg> I can make it smaller then 64 pixels, but when its smaller, the "paint" isn't updated and it doens't receive input from mouse and keyboard 20:32:04 <avdg> so far as I'm correct 20:33:44 <Rubidium> ah well, can't be bothered anymore. Just filed a bug report about OSX not obeying the 64x64 minimum size 20:34:11 <Rubidium> and those remaining crashes are "just" caused by that issue 20:35:21 <avdg> well, I'm happy openttd doesn't crash, for now 20:35:35 <planetmaker> :-) 20:35:58 <avdg> :p but its a kinda strange bugreport, isn't it 20:36:18 <Rubidium> what? FS#4070? 20:36:49 <avdg> no, the minimum size in general 20:37:17 <Rubidium> that it's missing? 20:37:36 <avdg> that too 20:37:41 <Rubidium> anything below 320x240 is (IMO) unplayable, so why should we even support those hypothetical cases? 20:37:49 <avdg> indeed 20:37:59 <Markk> Is there any port to Android? 20:38:13 <Rubidium> Markk: yes 20:38:20 <Markk> Ooh 20:38:23 <Markk> Nice 20:38:28 <Rubidium> whether it works I don't know 20:38:31 * avdg gives an reward for someone who invents openttd on 100x100 20:38:46 <Rubidium> probably won't ever get on android market either 20:39:13 <Wolf01> Rubidium, yes I play it on my 8x8 led matrix :D 20:39:32 <Wolf01> a bit pixelated... 20:40:40 <Markk> Rubidium: you know where I can find it? 20:40:44 <Markk> Googled a bit for it. 20:40:48 <Markk> Only threads. 20:41:11 <Rubidium> nope, just got a mail of someone saying he had made one 20:41:15 <Markk> ah 20:42:32 *** LunarWolf [~LunarWolf@age193.neoplus.adsl.tpnet.pl] has quit [Quit: Bye for now!] 20:44:35 <Rubidium> Markk: google should have it: http://code.google.com/p/openttd-android/ 20:46:08 *** Zuu [Zuu@c-2df1e655.510-8-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving] 20:46:57 *** frosch123 [~frosch@frnk-590fc895.pool.mediaWays.net] has quit [Remote host closed the connection] 20:49:39 *** welshdragon [~dragon@millsie.net] has joined #openttd 20:50:02 *** tokai [~tokai@port-92-195-53-177.dynamic.qsc.de] has joined #openttd 20:50:05 *** mode/#openttd [+v tokai] by ChanServ 20:50:18 <PeterT> I hate those damn patched servers that make everyone think that /reset is a valid command 20:50:31 <Eddi|zuHause> <Agame> how many days are there in openttd calendar? <-- it's a zero-based normalized gregorian calendar, so 365.2425 days 20:51:06 <Eddi|zuHause> hm, i guess he's already gone 20:53:10 <Vitus> OpenTTD obeys this completly, right? (I mean, leap year every 4 years, no leap year every 100 years and leap year every 400 years) 20:53:27 <Eddi|zuHause> yes 20:54:03 <Eddi|zuHause> and opposing to the real historical calendars, it hss a year 0 20:54:18 <Eddi|zuHause> historically, it jumped from -1 to +1 20:55:16 *** Sacro [~Sacro@87.102.12.231] has joined #openttd 20:56:02 * avdg wonders if there is someone playing before the year 0 20:56:16 <Eddi|zuHause> that is not possible 20:56:33 <Eddi|zuHause> openttd starts in year 0 and ends in year 5000000 20:56:53 <Eddi|zuHause> which amounts to the number of days Rubidium mentioned above 20:57:32 <Eddi|zuHause> @calc 5*10**6*365.2425 20:57:32 <DorpsGek> Eddi|zuHause: 1826212500 20:58:16 <Eddi|zuHause> @calc 2**31 20:58:16 <DorpsGek> Eddi|zuHause: 2147483648 20:59:52 <Rubidium> @calc 0.2425*400 20:59:52 <DorpsGek> Rubidium: 97 21:00:36 <Eddi|zuHause> @calc 1/4-1/100+1/400 21:00:36 <DorpsGek> Eddi|zuHause: 0.2425 21:00:43 <Rubidium> @calc 1826212865 - 1826212500 21:00:43 <DorpsGek> Rubidium: 365 21:01:01 <Rubidium> ah yes... that explains 21:01:09 <Eddi|zuHause> well. ot 21:01:14 <Eddi|zuHause> bÀhrgs 21:01:28 <Eddi|zuHause> it's 5000001 years 21:04:46 *** TomyLobo [~foo@port-212-202-171-176.dynamic.qsc.de] has quit [Quit: A key, command, or action that tells the system to return to a previous state or stop a process.] 21:08:42 <Wolf01> 'night 21:08:48 *** Wolf01 [~wolf01@host176-238-dynamic.0-87-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.] 21:13:00 *** orudge` [~orudge@c-75-73-67-58.hsd1.mn.comcast.net] has joined #openttd 21:13:03 *** mode/#openttd [+o orudge`] by ChanServ 21:15:20 <Rubidium> the legal alien has arrived, just not quite in New York it seems :) 21:16:30 *** LunarWolf [~LunarWolf@age193.neoplus.adsl.tpnet.pl] has joined #openttd 21:18:39 <LunarWolf> I installed OpenTTD whole again and I noticed that: 21:18:56 <TruePikachu> Could someone please integrate FS#4065 for me, please? 21:19:10 <LunarWolf> 32bpp_extra-nightly-R38 has a conflict with baseset_12-03-10 21:19:15 *** orudge` [~orudge@c-75-73-67-58.hsd1.mn.comcast.net] has quit [Quit: Goodbye.] 21:20:10 <TruePikachu> It would be nice if you can tell how much your game is lagging, especially with development now, where lots of things contrubute to lag ;) 21:20:43 *** Sacro [~Sacro@87.102.12.231] has quit [Remote host closed the connection] 21:21:47 <LunarWolf> contru... what? 21:22:25 <TruePikachu> LunarWolf: That was not exactly @ you 21:22:43 <TruePikachu> I just want to know how much my game lags, so I made FS#4065 21:23:32 <TruePikachu> The computer was built for Win98, and I put Linux on it 21:24:19 <TruePikachu> Slackware, of course, to get the best preformance, but OpenTTD is being a bit sluggish graphics-wise with 120 vehicles 21:24:26 <LunarWolf> FS # 40650 - do not know the 21:24:39 <TruePikachu> ? FS#4065 21:24:44 <TruePikachu> No zero at the end 21:25:22 <Rubidium> LunarWolf: just ignore him :) 21:25:28 <PeterT> lol pwnt 21:25:38 <PeterT> LunarWolf: http://bugs.openttd.org/taskk/4065 21:26:04 <TruePikachu> ^ that's wrong too, you put two Ks 21:26:17 <TruePikachu> http://bugs.openttd.org/task/4065 21:26:46 *** yorick [yorick@free.cookies.at.shellium.org] has quit [Remote host closed the connection] 21:27:15 <TruePikachu> Rubidium: Why do you keep thinking I'm trying to troll? 21:27:18 <Eddi|zuHause> TruePikachu: TT (original) ran slightly laggish on a 486DX66 with a 256^2 map with 80 trains and ~360 vehicles total. 21:28:14 <TruePikachu> Eddi|zuHause: Well, This is a PIII running at 800MHz, 192MB RAM, and it seems to lag on 120 vehicles total 21:28:29 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 21:28:36 <TruePikachu> Although I am not sure if it's preformance lag or graphics lag 21:28:41 <Eddi|zuHause> vehicles being each wagon counted individually 21:28:51 <TruePikachu> (i.e. if each tick is still 30ms) 21:29:01 <TruePikachu> Eddi|zuHause: Oh, well, see previous comment 21:29:07 *** Noldo_ [vheino@jumi.lut.fi] has joined #openttd 21:29:15 <LunarWolf> I will not have problems with using such number of trains 21:29:41 <TruePikachu> Well, I can't really upgrade my computer anytime soon ;) 21:30:23 *** Noldo [vheino@jumi.lut.fi] has quit [Ping timeout: 480 seconds] 21:30:28 <TruePikachu> It would be nice if there was a way to measure lag 21:31:12 <Eddi|zuHause> currently the most time consuming part is AIs using up all available opcodes 21:31:21 <TruePikachu> That's why I created FS#4065 - it tells you how fast the graphics are being, and how fast the game is being 21:31:28 <Eddi|zuHause> you can reduce that number, but afair not during a running game 21:31:35 <TruePikachu> ...at least, it would tell you if implimented 21:31:49 * andythenorth is looking for European bo-bo locomotives to MOC in Lego 21:32:03 <andythenorth> got to be full width body 21:32:51 *** Sacro [~Sacro@87.102.12.231] has joined #openttd 21:33:01 *** Vitus [~chatzilla@138.194.wms.cz] has quit [Quit: Good bye] 21:33:01 <LunarWolf> old times, I have 2 computers, the one currently in use, and the second is the 3D graphics, animation, rending 21:33:42 <Eddi|zuHause> andythenorth: E04, E18, E11, E03? (not sure if they really all were Bo'Bo') 21:33:48 <TruePikachu> Xrufuian told me at one point that he could get old parts from his upgrading of his computers 21:34:15 <TruePikachu> But school, the only place where I could actually _get_ the parts themselves, doesn't start for 3 more weeks 21:34:54 <TruePikachu> So, for right now, I would need a software solution 21:35:00 <LunarWolf> OMG. Even three hours rendering 21:36:43 <TruePikachu> I'm not sure, but KDE may be causing part of the problem 21:37:38 <TruePikachu> It would be nice if I could find an X server which will run JUST OpenTTD, instead of tons of background components as well 21:38:24 <TruePikachu> (i.e. I could just do something like "<x server> openttd" from the terminal) 21:38:35 * andythenorth searches for Lego parts that suit 21:39:37 <TruePikachu> andythenorth: Are your parts sorted? 21:39:49 <andythenorth> sort of :P 21:39:54 <TruePikachu> Mine aren't 21:40:04 <andythenorth> I have to buy more for a new train though 21:40:07 <TruePikachu> I have this big tub full of Legos 21:40:16 <TruePikachu> None of them are sorted :P 21:40:41 <TruePikachu> Pain in the butt and pain in the hands 21:40:48 *** Sacro [~Sacro@87.102.12.231] has quit [Read error: Connection reset by peer] 21:40:52 <andythenorth> I have a tub like that 21:41:03 <andythenorth> I need to sort it :P 21:41:30 * andythenorth thinks an engine like the Rb family might be good http://www.trenulete.ro/index.php?ml=51&art=3&lang=ENG 21:42:17 <andythenorth> or a v220 21:42:44 *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 21:43:03 <avdg> :/ why didn't I report other issues *blames hisself* 21:43:19 * avdg still knows 1 issue 21:44:47 <LunarWolf> 32bpp_extra-nightly-R38 is incompatible, the signals are not working properly 21:45:00 <Rubidium> andythenorth: doesn't look in any way like my family 21:45:28 <Rubidium> LunarWolf: you're better off writing such stuff in the 32bpp graphics subforum 21:45:47 <Rubidium> because most here can't be really bothered with the whole extrazoom 32bpp graphics stuff 21:47:34 <LunarWolf> 32bpp_extra-nightly-R28 and it works correctly 21:47:41 *** Sacro [~Sacro@87.102.12.231] has joined #openttd 21:54:23 *** KouDy [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 21:55:26 *** Giant [~Giant@dhcp-077-248-029-049.chello.nl] has quit [Quit: Byez] 21:57:04 *** LunarWolf [~LunarWolf@age193.neoplus.adsl.tpnet.pl] has quit [Quit: Bye for now!] 21:57:20 *** Devroush [~dennis@94-225-67-91.access.telenet.be] has quit [] 22:01:58 *** Devroush [~dennis@94-225-67-91.access.telenet.be] has joined #openttd 22:04:31 *** Sacro [~Sacro@87.102.12.231] has quit [Read error: Connection reset by peer] 22:05:30 *** Sacro [~Sacro@87.102.12.231] has joined #openttd 22:09:56 *** Yexo [~Yexo@ip51cca4b5.adsl-surfen.hetnet.nl] has quit [Ping timeout: 480 seconds] 22:18:33 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 22:19:24 *** Noldo_ is now known as Noldo 22:30:32 <Terkhen> good night 22:30:38 <avdg> gn 22:32:43 <Eddi|zuHause> andythenorth: if you're gonna build an engine, you should be building http://de.wikipedia.org/wiki/DRB-Baureihe_E_94 but that is Co'Co' 22:33:44 <Eddi|zuHause> andythenorth: and the page you linked to opens in editor, not in browser [probably wrong mime type] 22:35:36 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ] 22:36:07 *** [com]buster [~marcel@cust-03-55bf402e.adsl.scarlet.nl] has quit [Remote host closed the connection] 22:37:23 *** asilv [~as@h-62-142-160-55.joensuunelli.fi] has quit [] 22:59:37 *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has joined #openttd 22:59:39 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has quit [Ping timeout: 480 seconds] 23:06:47 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 23:24:33 *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Quit: Leaving.] 23:36:54 *** keoz [~keikoz@pha75-8-82-230-2-115.fbx.proxad.net] has quit [Quit: keoz] 23:40:58 *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 23:41:41 *** Sacro [~Sacro@87.102.12.231] has quit [Read error: Connection reset by peer] 23:47:08 *** KritiK [~Maxim@95-25-213-167.broadband.corbina.ru] has quit [Quit: Leaving] 23:47:25 *** De_Ghosty [~s@206-248-186-123.dsl.teksavvy.com] has quit [Remote host closed the connection] 23:51:33 *** DDR [~DDR@d99-199-12-91.bchsia.telus.net] has quit [Quit: In democracy it's your vote that counts; In feudalism it's your count that votes. - Mogens Jallberg] 23:52:20 *** Biolunar [Mahdi@blfd-5d822a53.pool.mediaWays.net] has quit [] 23:55:10 * TruePikachu is watching the LED counter