Log for #openttd on 22nd August 2010:
Times are UTC Toggle Colours
00:02:43  *** fmauneko [] has quit [Ping timeout: 480 seconds]
00:12:20  *** a1270 [] has quit [Remote host closed the connection]
00:12:42  *** avdg [] has quit [Quit: Leaving.]
00:13:30  *** a1270 [] has joined #openttd
00:16:16  *** Brianetta [] has quit [Quit: TschÌß]
00:17:07  *** Devroush [] 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 [] has quit []
00:52:55  *** KritiK [] 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 [] 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 [] 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_ [] has joined #openttd
01:45:48  *** Progman [] has quit [Ping timeout: 480 seconds]
01:46:00  *** Progman_ is now known as Progman
01:53:10  *** Progman [] 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 [] 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@] has joined #openttd
02:30:55  *** rhaeder1 [] has quit [Ping timeout: 480 seconds]
02:33:17  *** ajmiles [] 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 [] 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 [] has quit [Remote host closed the connection]
04:26:33  <TruePika> ...I'm back and no conversation went on???
04:29:14  *** roboboy [] 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 [] has quit [Remote host closed the connection]
04:56:21  *** Eddi|zuHause2 [] has joined #openttd
05:36:43  *** a1270 [] has quit [Quit: Leaving]
05:36:53  *** roboboy [] has quit [Ping timeout: 480 seconds]
05:37:08  *** George [~George@] has quit [Read error: Connection reset by peer]
05:45:24  *** George [~George@] has joined #openttd
06:09:43  *** KouDy [] has joined #openttd
06:23:09  *** Kurimus [] has joined #openttd
06:28:28  <TruePika> Well, it's 11:30 here, night
06:28:36  *** TruePika [] has quit [Quit: night]
06:37:45  *** ^Spike^ [] has joined #openttd
06:46:06  *** Zuu [] has joined #openttd
07:16:13  * andythenorth ponders
07:23:34  *** roboboy [] has joined #openttd
07:26:51  *** tokai|mdlx [] has quit [Quit: c('~' )o]
07:27:57  *** a1270 [] has joined #openttd
07:28:49  <Terkhen> good morning
07:36:10  <Wolf01> morning
07:49:10  *** Alberth [~hat@] 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 [] 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 [] has joined #openttd
07:54:13  <Alberth> isn't it simply the file that tortoise complains about?
07:54:36  *** roboboy [] has quit [Read error: Connection reset by peer]
07:55:02  *** roboboy [] 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 [] 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 [] 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 [] has joined #openttd
08:41:03  *** theholyduck [~holyduck@] has quit [Read error: Connection reset by peer]
08:49:12  *** Progman [] 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 [] has quit [Ping timeout: 480 seconds]
09:07:47  *** ^Spike^ [] has quit [Remote host closed the connection]
09:09:10  *** ^Spike^ [] 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 [] 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 [] 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@] 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 [] 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>
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>
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@] has quit [Quit: Leaving]
10:52:46  <planetmaker> it's not directly related to the window size:
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 [] 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 [] has joined #openttd
11:09:36  <VVG> , 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 [] 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 [] 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 [] has joined #openttd
11:24:46  <planetmaker> <-- 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 [] 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 [] 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 [] 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> 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 [] 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 [] 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 [] has quit [Remote host closed the connection]
12:21:53  *** Sacro_ [] 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 [] 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 [] 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 [] has joined #openttd
12:30:04  *** Sacro_ [] has quit [Ping timeout: 480 seconds]
12:34:42  <Alberth> only a warning :)
12:35:58  *** Adambean [] has joined #openttd
12:37:26  *** lugo [] has joined #openttd
12:38:20  *** Sacro [] 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 [] 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>
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 [] has quit [Ping timeout: 480 seconds]
12:54:09  <avdg> it normally can't hurt, depending on the coding style
12:54:22  *** KouDy [] has joined #openttd
12:54:48  *** GVV [~sdfkhksd@] 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@] 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>
12:59:03  <VVG> very handy, thanks
13:00:35  *** Brin [] 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:
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> 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@] 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 [] 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 [] has joined #openttd
13:53:55  <andythenorth> hmmm
13:53:58  *** Biolunar [] 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:
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 [] has joined #openttd
14:27:03  *** Progman [] has quit [Remote host closed the connection]
14:35:15  <planetmaker> <-- that savegame crashes upon load, Rubidium
14:35:30  <planetmaker> that's the most recent one from the PS
14:46:47  *** JVassie [~James@] has joined #openttd
14:49:58  *** HerzogDeXtEr [~Flex@] has joined #openttd
14:49:59  *** HerzogDeXtEr1 [~Flex@] has quit [Read error: Connection reset by peer]
14:55:39  *** Yexo [] 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 [] has quit [Quit: bye]
15:29:03  *** Zuu [] has quit [Ping timeout: 480 seconds]
15:42:08  *** nicfer [~nicfer@] 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:
15:51:28  <planetmaker> <-- 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]] 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@] 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@] 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>
16:11:42  <Rubidium> you can to
16:13:53  <Pixo[hol]>
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 [] has joined #openttd
16:22:27  *** sparr [] has quit [Remote host closed the connection]
16:24:33  *** sparr [] 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>
16:43:48  *** [com]buster [] 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: 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 [] has quit [Remote host closed the connection]
16:54:05  * Rubidium wonders how many in here recognise (parts of)
16:54:44  *** Sacro [] has joined #openttd
16:56:03  *** Cybertinus [] has joined #openttd
16:57:21  *** Sacro [] has quit [Read error: Connection reset by peer]
16:58:34  *** Yexo [] has joined #openttd
16:59:28  *** Sacro [~ben@] has joined #openttd
16:59:49  * Rubidium waves in the general direction of Vjenne
17:00:25  *** Sacro [~ben@] 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 [] 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 [] 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@] has quit [Read error: Connection reset by peer]
17:03:49  <Eddi|zuHause> good morning everybody.
17:03:58  *** roboboy [] 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@] has joined #openttd
17:06:44  * frosch123 does not recognise any parts
17:10:50  *** Cybertinus [] 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]] has left #openttd []
17:26:25  *** Progman [] 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 [] has joined #openttd
17:31:50  *** jordi [] has quit [Ping timeout: 480 seconds]
17:33:42  <avdg> lol
17:34:08  <avdg> actually not so funny :/
17:35:21  <Rubidium> yay for social engineering :(
17:37:37  *** avdg [] has quit [Read error: Connection reset by peer]
17:37:54  *** avdg [] has joined #openttd
17:44:20  *** roboboy [] 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@] has quit [Excess Flood]
17:56:06  *** Vitus [] has joined #openttd
17:58:26  *** jordi [] has joined #openttd
17:59:31  *** ProfFrink [] 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 [] has quit [Ping timeout: 480 seconds]
18:05:13  *** ProfFrink is now known as Prof_Frink
18:07:12  *** fmauneko [~fmauneko@] 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 [] has quit [Remote host closed the connection]
18:13:35  *** fmauneko [~fmauneko@] has quit [Quit: fmauneko]
18:14:10  *** Cybertinus [] has joined #openttd
18:15:16  *** avdg [] has quit [Remote host closed the connection]
18:15:35  *** avdg [] has joined #openttd
18:30:58  *** DDR [] 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>
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 [] 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>
18:44:06  <andythenorth> I need to fix that one :)
18:44:32  *** Zuu [] 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@] has joined #openttd
18:45:40  <planetmaker> andythenorth: checkout the FS entry again
18:46:06  *** Cybertinus [] has joined #openttd
18:46:10  *** devilsadvocate [~devilsadv@] 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@] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
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@] 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@] has quit [Ping timeout: 480 seconds]
18:58:53  *** Sacro [~ben@] has quit [Ping timeout: 480 seconds]
18:58:56  *** devilsadvocate [~devilsadv@] has joined #openttd
19:01:51  *** Sacro [~ben@] has joined #openttd
19:05:01  *** Sacro_ [~ben@] has quit [Ping timeout: 480 seconds]
19:05:25  <avdg> looks like we have another crash :(
19:06:00  <avdg>
19:07:06  *** devilsadvocate [~devilsadv@] 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@] has quit [Ping timeout: 480 seconds]
19:10:14  *** Brianetta [] has quit [Quit: TschÌß]
19:10:15  <Rubidium> and that ancient 0.3.[34] savegame you're loading
19:12:04  *** Kurimus [] 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 [] 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@] 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 [] 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
19:30:54  <avdg> I know, he's kinda lazy :p
19:31:02  <Giant> (A)
19:32:31  <Rubidium> avdg, planetmaker: does 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>
19:53:59  <avdg> I've run openttd in an other cli tab
19:54:02  *** LunarWolf [] has joined #openttd
19:54:17  <Giant> < - 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@] 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 [] has quit [Quit: Gone fishing]
19:58:47  <Rubidium> LunarWolf: 32bpp graphics?
19:58:56  <LunarWolf> yep
19:59:04  <avdg>
19:59:05  <Rubidium> then (s)he's most likely not here
19:59:15  *** Agame [] 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>
20:05:25  <planetmaker> Rubidium: you OpenTTD window gets forced to 64^2 pixels?
20:06:09  *** Agame [] 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 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>
20:12:24  <LunarWolf> PCX unpacked correctly
20:12:38  *** Zuu [] 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 [] 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@] 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 [] has quit [Quit: Bye for now!]
20:44:35  <Rubidium> Markk: google should have it:
20:46:08  *** Zuu [] has quit [Quit: Leaving]
20:46:57  *** frosch123 [] has quit [Remote host closed the connection]
20:49:39  *** welshdragon [] has joined #openttd
20:50:02  *** tokai [] 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@] 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 [] 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 [] has quit [Quit: Once again the world is quick to bury me.]
21:13:00  *** orudge` [] 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 [] 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` [] 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@] 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:
21:26:04  <TruePikachu> ^ that's wrong too, you put two Ks
21:26:17  <TruePikachu>
21:26:46  *** yorick [] 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 [] 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_ [] 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 [] 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> 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@] has joined #openttd
21:33:01  *** Vitus [] 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@] 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
21:42:17  <andythenorth> or a v220
21:42:44  *** dfox [] 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@] has joined #openttd
21:54:23  *** KouDy [] has quit [Ping timeout: 480 seconds]
21:55:26  *** Giant [] has quit [Quit: Byez]
21:57:04  *** LunarWolf [] has quit [Quit: Bye for now!]
21:57:20  *** Devroush [] has quit []
22:01:58  *** Devroush [] has joined #openttd
22:04:31  *** Sacro [~Sacro@] has quit [Read error: Connection reset by peer]
22:05:30  *** Sacro [~Sacro@] has joined #openttd
22:09:56  *** Yexo [] has quit [Ping timeout: 480 seconds]
22:18:33  *** Cybertinus [] 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 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 [] has quit [Quit: TschÌß]
22:36:07  *** [com]buster [] has quit [Remote host closed the connection]
22:37:23  *** asilv [] has quit []
22:59:37  *** dfox [] has joined #openttd
22:59:39  *** ^Spike^ [] has quit [Ping timeout: 480 seconds]
23:06:47  *** roboboy [] has joined #openttd
23:24:33  *** avdg [] has quit [Quit: Leaving.]
23:36:54  *** keoz [] has quit [Quit: keoz]
23:40:58  *** dfox [] has quit [Ping timeout: 480 seconds]
23:41:41  *** Sacro [~Sacro@] has quit [Read error: Connection reset by peer]
23:47:08  *** KritiK [] has quit [Quit: Leaving]
23:47:25  *** De_Ghosty [] has quit [Remote host closed the connection]
23:51:33  *** DDR [] 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 [] has quit []
23:55:10  * TruePikachu is watching the LED counter

Powered by YARRSTE version: svn-trunk