IRC logs for #openttd on OFTC at 2009-12-11
⏴ go to previous day
00:28:05 *** ChanServ sets mode: +v glx_
00:30:06 *** glx is now known as Guest1171
00:33:31 *** Eddi|zuHause has joined #openttd
00:53:18 *** JVassie has joined #openttd
01:14:32 *** Rubix`` has joined #openttd
01:32:50 *** KenjiE20|LT has joined #openttd
02:05:13 *** De_Ghosty has joined #openttd
02:26:17 <PeterT> Perhaps somebody could add 'forum' to the list of *.openttd.org in the topic
02:35:18 *** Rubix`` has joined #openttd
02:48:49 <Belugas> huu?? this that late??
02:49:11 <Belugas> ho...Sacro... ok, i still hjave time :)
02:49:21 <Belugas> hello Sacro, my friend!
02:53:43 <Belugas> 21:53h, and i need to fill my glass :)
03:18:16 *** Rexxars has joined #openttd
03:26:39 <fjb> Almost time for bed here.
03:31:03 *** DaleStan has joined #openttd
04:00:47 *** DarkED2 has joined #openttd
05:17:27 *** DaleStan_ has joined #openttd
05:17:28 *** DaleStan is now known as Guest1203
05:17:28 *** DaleStan_ is now known as DaleStan
07:01:40 *** JVassie has joined #openttd
07:05:44 *** andythenorth has joined #openttd
07:21:56 *** Cybertinus has joined #openttd
07:29:28 *** Polygon has joined #openttd
08:36:46 *** andythenorth has joined #openttd
09:05:04 *** DaleStan_ has joined #openttd
09:05:04 *** DaleStan is now known as Guest1230
09:05:04 *** DaleStan_ is now known as DaleStan
09:05:26 *** bartaway is now known as bartavelle
09:10:51 *** bartavelle is now known as bartaway
09:11:11 *** bartaway is now known as bartavelle
09:16:05 *** Terkhen has joined #openttd
09:19:51 *** andythenorth has joined #openttd
09:22:29 *** fonsinchen has joined #openttd
09:33:21 *** Progman has joined #openttd
09:42:28 *** andythenorth has joined #openttd
09:57:05 *** andythenorth has joined #openttd
10:27:10 *** Chris_Booth has joined #openttd
10:31:25 *** andythenorth has joined #openttd
10:42:11 *** |Terkhen| has joined #openttd
10:50:38 *** |Terkhen| is now known as Terkhen
11:03:03 *** andythenorth has joined #openttd
11:21:29 <CIA-4> OpenTTD: rubidium * r18455 /extra/website/frontpage/templates/frontpage/about.html: [Website] -Add: mention of the officially supported OSes
11:23:05 <Eddi|zuHause> did you remove osx yet? :p
11:24:44 <Rubidium> no, didn't add Mac OS X 10.6 though
11:26:06 <Eddi|zuHause> windows is not as horribly broken as its reputation ;)=
11:34:35 <blathijs> TrueBrain: I'll upload a new version next week, if that's what you're referring to :-)
11:34:51 <blathijs> Being a tad busy with my graduation presentation, which next monday...
11:35:27 *** welshdragon has joined #openttd
11:35:50 <Eddi|zuHause> hm... should i be worried about having a "skynet.sys"?
11:38:15 <TrueBrain> blathijs: concratz ;) (on the latter, not the former)
11:49:52 *** Singaporekid has joined #openttd
11:56:21 *** ChanServ sets mode: +v tokai
12:21:25 *** |Terkhen| has joined #openttd
12:43:48 *** |Terkhen| is now known as Terkhen
12:50:00 *** bartavelle is now known as bartaway
12:54:01 *** oskari89 has joined #openttd
13:01:15 *** DaleStan_ has joined #openttd
13:01:15 *** DaleStan is now known as Guest1253
13:01:15 *** DaleStan_ is now known as DaleStan
13:10:41 *** JVassie has joined #openttd
13:12:28 *** bartaway is now known as bartavelle
13:15:09 *** KenjiE20 has joined #openttd
13:31:50 *** bartavelle is now known as bartaway
13:37:13 <CIA-4> OpenTTD: rubidium * r18456 /trunk/src/train_cmd.cpp: -Codechange: make the length checking functionality of CmdMoveRailVehicle a separate function and simplify the logic
13:40:06 *** HerzogDeXtEr has joined #openttd
13:58:52 *** bartaway is now known as bartavelle
14:10:00 *** LordAzamath has joined #openttd
14:14:01 *** Chruker has joined #openttd
14:20:26 *** Chris_Booth has joined #openttd
14:34:09 *** bartavelle is now known as bartaway
14:58:46 *** |Jeroen| has joined #openttd
15:05:32 *** bartaway is now known as bartavelle
15:16:56 <CIA-4> OpenTTD: yexo * r18457 /trunk/src/genworld_gui.cpp: -Fix (r18015): southwest and northeast buttons for freeform edges were swapped
15:18:11 <fjb> Hm, how can I force 4 byte alignment of a variable in C?
15:18:41 <Rubidium> doesn't that automatically happen?
15:18:53 <Rubidium> unless you enable packing
15:20:25 <fjb> gcc complains that packing is not needed. uint32_t is correctly aligned. But I fear that uint8_t x[3] or something like that may have an uneven alignment.
15:21:17 <Rubidium> why does it need to be 4 byte aligned?
15:21:45 <Rubidium> i.e. what do you want to do?
15:21:59 <fjb> I want to cast a void * to a uint32_t *.
15:22:25 <Yexo> I can't htink of a valid reason either, but if you really need to the syntax for gcc is: __attribute ((aligned (4)))
15:24:14 <fjb> I have an array of type uint_8. At one place a pointer to that gets casted to a void * and that to an uint32_t *.
15:25:24 <Yexo> you do realisze that if the size of the array is 3 then you're doing an illegal memory access?
15:26:01 <Yexo> and if the array is size 4 or bigger, then the worst that can happen is that you do an unaligned memory get, while maybe slow it's valid
15:32:56 *** Alberth has joined #openttd
15:50:19 <CIA-4> OpenTTD: rubidium * r18458 /trunk/src/train_cmd.cpp: -Codechange: make the 'check train length' code of CmdMoveRailVehicle a separate function
15:53:57 *** Coco-Banana-Man has joined #openttd
15:56:40 *** Dred_furst has joined #openttd
15:58:34 *** andythenorth has joined #openttd
16:02:21 <fjb> Yexo: That was a bad example. The array is bigger.
16:04:16 <fjb> But I have the problem that *(uint8_t *)voidptr = byte_variable works, but *(uint32_t *)voidptr = long_variable doesn't.
16:06:14 <fjb> But the uint8_t array is already long aligned. I just looked where it is located in memory.
16:06:17 <Yexo> how "it doesn't work"? Does it compile?
16:06:44 <Yexo> isn't it big/little endian that has you confused?
16:07:11 <fjb> It compiles without warning or error. But the memory which the voidptr is pointing at does not change.
16:08:54 <fjb> Bir or little endian would just swap the bytes. *voidptr is 0x00000000. byte_variable is 0xff. long_variable is 0x0000ffff.
16:09:46 <fjb> In case of the *(uint8_t *)voidptr = byte_variable; *voidptr changes to 0x000000ff.
16:10:30 <fjb> In case of the *(uint32_t *)voidptr = long_variable; *voidptr remains 0x00000000.
16:10:34 <Yexo> and ou do cast to uint when examining the voidptr?
16:11:16 <Rubidium> what if you cast the long_variable to (uint32_t) first?
16:11:55 <fjb> My actual solution is to cast void_ptr to uint8_t * anc copy byte wise in a for loop.
16:12:42 * Rubidium still doesn't get what fjb wants to actually do though
16:12:55 <Yexo> have you tried creating an intermediate uint32_t pointer? ie something like uint32_t *newptr = (uint43_t*)void_ptr; *newptr = long_var;
16:13:28 <Rubidium> copying some array into another? Then why not memcpy?
16:13:30 *** HerzogDeXtEr has joined #openttd
16:13:51 <fjb> Yes, I also did that. But *voidptr still did not change.
16:14:47 <fjb> I wanted to avoid a subroutine call.
16:14:51 <Rubidium> anyhow... give us some actually code, not snippets, so we can see for ourselves if you want to get some proper answer fast
16:15:40 <Yexo> I'd assume that on most compilers memcpy would be inlined anyway
16:16:50 <CIA-4> OpenTTD: rubidium * r18459 /trunk/src/train_cmd.cpp: -Codechange: move the new train validity checking (attach callbacks) to a separate function
16:18:17 <fjb> Then inlined code could be faster.
16:23:01 <Alberth> not to mention that compilers may have generate code for doing memcpy() as fast as possible
16:24:52 <fjb> Line 505 reads a uint32_t and one char, short or long has to be copied to *rx_data
16:40:26 <Alberth> where do you print the void * result?
16:41:15 <Alberth> in particular, do you print data from the place where you wrote it ?
16:45:17 <fjb> line 535... in this version. I have a look if I still have the not working version.
16:56:24 <fjb> Both are only working in case of bpst == 1
16:57:06 *** |Jeroen| has joined #openttd
16:58:45 <fjb> But memcpy would be the best solution, I guess.
17:01:07 *** Rhamphoryncus has joined #openttd
17:14:55 *** Eddi|zuHause has joined #openttd
17:19:43 *** Eddi|zuHause has joined #openttd
17:20:57 *** ChanServ sets mode: +v tokai
17:21:42 <xopek> to expand the menu of signals, openttd patch should?
17:22:38 *** frosch123 has joined #openttd
17:23:51 <xopek> I do not know how to say angel. only to understand:)
17:24:24 <Eddi|zuHause> sed you obviously know ;)
17:26:59 <Eddi|zuHause> so, what are you asking?
17:27:17 <Eddi|zuHause> i have a patch somewhere that adds two signal types to the menu
17:27:34 <Eddi|zuHause> if that's what you want
17:28:26 <Eddi|zuHause> they won't magically get new functionality, though ;)
17:32:21 <xopek> hm. In the instructions for use written about the 6 types of semaphores. Here I would get them.
17:32:54 <xopek> google translator breaks sometimes.. :-)
17:34:44 <Eddi|zuHause> i'm still not sure what you mean...
17:35:21 <Rubidium> especially because the stable already has 6 types of signals
17:35:36 <xopek> just do not was included menu signals...
17:35:50 <Eddi|zuHause> so you want to show the signal menu?
17:36:03 <Eddi|zuHause> that's in advanced settings -> interface
17:36:48 <xopek> just include a menu of signals. while no more questions :-)
17:37:53 <Eddi|zuHause> hm.... dd_rescue is cool, the disk is totally in the toilet, but it still has no read error...
17:42:41 *** Polygon has joined #openttd
17:46:11 *** bartavelle is now known as bartaway
18:00:26 *** andythenorth has joined #openttd
18:02:59 <Eddi|zuHause> 5 Reallocated_Sector_Ct 0x0033 001 001 005 Pre-fail Always FAILING_NOW 1384
18:17:57 <fjb> Alberth: memcpy is 3µs slower than my for loop at 2byte transfers.
18:18:40 <Alberth> 2 bytes a time is pretty much nothing
18:19:09 <Alberth> ie it is 1/2 a register
18:19:28 <fjb> But more bytes are not needed, most times just one byte. Sometimes maybe 4 bytes.
18:19:52 <fjb> Yes, but the ADC has "only" 16 bit.
18:20:19 <Eddi|zuHause> so i have 60kb of unreadable data
18:20:32 <Eddi|zuHause> problem is, part of that data seems to be a directory
18:20:37 <frosch123> 16bit adc, only saw 8/10/12, and slow 24
18:22:03 <Eddi|zuHause> why is there no ntfsck?
18:23:56 <Rubidium> Eddi|zuHause: because that's called chkdsk
18:24:15 <Eddi|zuHause> Rubidium: does that run under wine? :p
18:24:30 <frosch123> [19:22] <Eddi|zuHause> why is there no ntfsck? <- i have
18:24:40 <frosch123> never ran it though :p
18:24:55 <Eddi|zuHause> where does that come from?
18:25:28 <frosch123> most likely from "emerge sys-fs/ntfsprogs"
18:28:15 <Eddi|zuHause> hm... "ntfsundelete --optimistic"
18:29:15 <frosch123> hmm, maybe it just does "nothing" though
18:29:25 <frosch123> (google suggests that)
18:29:52 <Eddi|zuHause> my repository only has 1.13.1
18:40:18 <fjb> A simple if () costs almost 1µs. :-(
18:45:47 <CIA-4> OpenTTD: translators * r18460 /trunk/src/lang/ (7 files in 2 dirs): (log message trimmed)
18:45:47 <CIA-4> OpenTTD: -Update from WebTranslator v3.0:
18:45:47 <CIA-4> OpenTTD: catalan - 2 changes by arnau
18:45:47 <CIA-4> OpenTTD: traditional_chinese - 4 changes by josesun
18:45:47 <CIA-4> OpenTTD: croatian - 59 changes by UnderwaterHesus
18:45:49 <CIA-4> OpenTTD: french - 2 changes by glx
18:45:49 <CIA-4> OpenTTD: norwegian_bokmal - 34 changes by Zhygometh
18:49:15 <CIA-4> OpenTTD: rubidium * r18461 /trunk/src/train_cmd.cpp: -Fix (r18456): when moving a wagon from the front of a train one could make a train 1 longer than allowed
19:01:04 *** Eddi|zuHause has joined #openttd
19:13:30 *** andythenorth has joined #openttd
19:17:49 *** Brianetta has joined #openttd
19:19:17 <xopek> at the level of "hard", with the appearance in the game AI begins to brake. why?
19:27:25 <TrueBrain> Eddi|zuHause: really, I think you should never again touch HDs .. somehow you always break them
19:27:51 <Eddi|zuHause> actually, this one was broken for ages, i just never connected it again
19:28:00 <CIA-4> OpenTTD: rubidium * r18462 /trunk/src/train_cmd.cpp: -Fix: when moving a wagon and only the last part of a dual headed engine you could split the dual headed engine over two vehicles.
19:28:40 <CIA-4> OpenTTD: rubidium * r18463 /trunk/src/train_cmd.cpp: -Codechange: some simplifications for finding the end of a vehicle
20:03:32 <DarkED> you guys have got to see this station i've been working on
20:04:52 <DarkED> 19 platforms and it still cannot handle all the volume (i'm still getting some queueing)
20:06:05 <Eddi|zuHause> from this description, i am not inclined to see this station
20:06:47 <Eddi|zuHause> it's a) insanity, and b) a .jpg
20:06:58 <_ln> 19 tracks would only be a mid-size real-life station.
20:07:00 <DarkED> so? it's a jpg? what's the problem?
20:07:11 <_ln> (the previous line was not intended for readers in Québec)
20:07:13 <DarkED> _ln, i know, but in openttd that seems kinda massive
20:08:44 <DarkED> _ln, yes and it's also a low-filesize format considering
20:08:55 <DarkED> my monitor is 1080p... that doesn't make for small pngs
20:09:01 <Eddi|zuHause> DarkED: jpg removes all straight lines from pictures
20:09:12 <Eddi|zuHause> DarkED: computer screenshots consist to 100% of straight lines
20:09:26 <Eddi|zuHause> DarkED: so jpg remove 100% of information from screenshots
20:09:57 <Eddi|zuHause> plus, you downscaled the picture
20:10:18 <DarkED> Eddi|zuHause, doesn't really factor up that way. plus, openttd is played from an isometric diagonal perspective -- there are only diagonal lines. also photobucket downscaled it, not me
20:10:22 <Eddi|zuHause> and openttd screenshots are 8bpp, while jpegs are 32bpp, so automatically 4 times bigger
20:10:50 <DarkED> Rubidium, i see what you're getting at now
20:11:09 <Eddi|zuHause> there are plenty of reasons why jpeg is useless
20:11:22 *** Gremnon has joined #openttd
20:11:22 <Eddi|zuHause> not only aesthetical ones
20:11:31 <fjb> Beside the low quality of that picture the station looks boring. Often seen that kind and not very efficient.
20:12:51 <Eddi|zuHause> yeah, the lines from below should be distributed further to the right of the station, so the trains don't block each other as much
20:12:59 <fjb> And ofcourse there is only flat land, no interesting landscape or anything else to see.
20:13:36 <DarkED> fjb, that's okay, i think it's awesome personally
20:13:44 <Eddi|zuHause> DarkED: it doesn't actually matter whether the lines are to an angle, jpeg cannot handle straight lines at any angle
20:14:08 <Eddi|zuHause> DarkED: it's incapable of doing so by design
20:14:38 <DarkED> Eddi|zuHause, well, now i know the wonders of 256-color png
20:14:45 <DarkED> uh, for openttd that is
20:14:55 <fjb> Massive station from openttdcoop are awesome. Not that station.
20:15:11 <DarkED> fjb, stations in openttdcoop make no sense when you look at them
20:15:24 <DarkED> Sacro, it's always full
20:15:31 <DarkED> look at the screenshot
20:15:39 <frosch123> hmm, typical maglev station :p the trains need ages for loading compared to driving, so you needs dozands of platforms for a few entry liens
20:15:51 <Sacro> frosch123: could be, never use maglev
20:16:00 <Sacro> but with normal locos it'd only need around 8
20:16:08 <DarkED> frosch123, yeah... it's easier with electric engines
20:16:31 <Sacro> hang on, through the JPEG mist that looks like presignals
20:16:31 <DarkED> but if you notice the date it's 2129... maglev is the only type available to me at this point
20:16:53 * fjb would use ships to move a massive amount of coal.
20:17:16 <Eddi|zuHause> DarkED: and make sure the image hoster is set to "no rescaling"
20:17:43 <DarkED> Eddi|zuHause, it crops according to size. the jpg was over 1mb so it cropped
20:17:51 <fjb> Best way to make OpenTTD screen shots is with the build in screen shot function.
20:17:54 <DarkED> the 256color png is 800kb so it should be full size
20:17:55 <frosch123> DarkED: likely most in here play with wagon speed limits, so you hardly need lots of freight platforms
20:18:04 <Eddi|zuHause> DarkED: and to me it looks like the exit is the bottleneck, not the number of platforms
20:18:28 <DarkED> Eddi|zuHause, it's one of the bottlenecks, yes. i just don't have any space to add more outbound lines :(
20:18:46 <Eddi|zuHause> frosch123: with cargodist and timetabling of mixed passenger/freight lines, i need plenty of platforms for the intermediate freight stations
20:19:05 <DarkED> yes i agree that png looks so much better
20:19:15 <DarkED> it only dropped 300kb off the size, but much better
20:19:22 <Sacro> so you can only have one train leaving at a time
20:19:53 <frosch123> Eddi|zuHause: what? more platforms for more different directions? but... isn't that too realistic?
20:19:53 <Sacro> rather pointless having dual exit lanes
20:20:18 <DarkED> Sacro, those are one-way path signals. the trains actually do use both lanes
20:20:34 <DarkED> Rubidium, that map is insane
20:20:52 <Eddi|zuHause> frosch123: it's mainly that the freight trains do "hop from one freight station to the next, then wait there 10 minutes until the passenger train passes"
20:21:00 <fjb> I need a faster internet connection...
20:21:59 <DarkED> Rubidium, how do you get those ships to stack like that?
20:22:04 <DarkED> or do they just do that?
20:22:17 <DarkED> Sacro, no, they don't always use both lanes, just sometimes
20:22:30 <peter1138> ships don't collide
20:22:36 <DarkED> Sacro, unfortunately i'm not TOO good with signals... i don't know how to set it up properly
20:22:47 <DarkED> i just try to make it so there are no possibilities of collisions
20:22:55 <DarkED> peter1138, ahh, i didn't know that
20:23:17 <fjb> Ah, that scenario was the reason for implementing the aquaducts.
20:23:19 <DarkED> that is interesting... very interesting. i will have to play around with them
20:23:44 <Rubidium> 'only' 1 million cargo delivered per year (OTTDCoop's Pile Transport is only half a million, OTTDCoop's PS154 has only ~5% more delivered cargo)
20:24:11 *** LordAzamath has joined #openttd
20:24:43 <DarkED> glx, screenshot shortcut?
20:25:09 <DarkED> yeah but that dumps it as a full quality png
20:25:20 <DarkED> i'd still have to crack open irfanview and compress it
20:25:59 <glx> it outputs a 8bpp png if you use 8bpp blitter
20:26:08 <Eddi|zuHause> DarkED: generally, having 4 inbound lines and 2 outbound lines is asking for trouble
20:26:14 <PeterT> DarkED: What OS do you use?
20:26:20 <Eddi|zuHause> and i see plenty of space for expansion
20:26:32 <DarkED> PeterT, i flipflop alot. i switch between windows and linux
20:26:42 *** zodttd2 has joined #openttd
20:27:00 <Eddi|zuHause> Rubidium: now try that same thing with PBI: stockpile limits and expiring mines ;)
20:27:17 <DarkED> i use crunchbang on my desktop and my laptop. i run my own very light version of winxp pro that i made with nlite on my desktop. laptop is running win7 ultimate x64
20:28:32 <DarkED> PeterT, what do you use?
20:29:06 <PeterT> I'm an absolute noob to Linux
20:29:08 <DarkED> well... 9.10 has lots of issues that weren't present in 9.04
20:29:16 <DarkED> lots of bugs, a few bad memory leaks
20:29:26 <DarkED> in fact alot of ubuntu users are up in arms about it
20:29:34 <DarkED> people saying it shouldn't even have been a '1.0' release
20:29:44 <Lakie> How'd it make it out of the beta / release canditates with such issues?
20:29:47 <DarkED> yeah... X has some serious memory issues
20:30:07 <DarkED> Lakie, canonical likes to stick to a very strict release schedule. usually they release no matter what shape it's in
20:30:16 <DarkED> of course, until 9.10, there weren't any serious problems
20:30:20 <DarkED> they release every six months
20:30:26 <Lakie> Wouldn't that affect most major releases around the time if X was the problem?
20:30:32 <DarkED> the only time they ever broke the six month rule was with 6.06
20:30:37 <Rubidium> Lakie: simple, people don't dare to run the betas/RCs because they know how buggy the releases are, as such no beta/RC feedback and buggy releases
20:30:43 <DarkED> Lakie, it only happens on certain systems with X
20:30:58 <DarkED> Lakie, certain hardware has problems with memory leaks and 100% cpu usage from X
20:31:02 <DarkED> but most hardware is fine
20:31:11 <Lakie> Rubidium: I appreate that, since quite often I prefer not to run betas, myself.
20:31:17 <DarkED> regardless, there are still lots of other bugs present in the new version of Gnome
20:31:35 <DarkED> thats why i switched to crunchbang. it's built on ubuntu 9.04 and is much more stable
20:31:41 <Rubidium> Lakie: Ubuntu has to tendency to package stuff that is scheduled to be released a month before their release
20:31:43 <DarkED> i've been using ubuntu since 5.04
20:31:55 <DarkED> the golden age of ubuntu was between 6.06 and 7.10, tbh
20:32:02 <DarkED> everything before and after has been pretty much crap
20:32:07 <Rubidium> a sane distribution wouldn't do that, but then those distributions are 'old' and such
20:32:32 * Lakie likes openSUSE, but I suspect most people don't...
20:32:40 <DarkED> ubuntu started to become a very bloated ram hog around the time 8.04 came out
20:32:51 <DarkED> thats another reason i went to crunchbang
20:33:11 <Rubidium> Lakie: there are Ubuntu paid developers that package stuff to go into Ubuntu (because their boss says too) but aren't even trying to consider adding it to Debian because it's too buggy
20:33:38 <DarkED> Rubidium, well it depends on which version of debian you're running :D
20:33:49 <DarkED> one version is sane, the other is bleeding edge
20:33:53 <DarkED> i forget which is which
20:34:07 <DarkED> i thing etch is the bleeding edge release and lenny is the stable
20:34:17 <Rubidium> DarkED: etch is oldstable
20:34:24 <DarkED> okay so i have it backwards
20:34:38 <Rubidium> squeeze is testing, sid is 'unstable'
20:35:04 <DarkED> i've actually been tempted to try the newest version of fedora on my laptop. it has the ram and cpu to push such a bloated distro
20:36:00 <Rubidium> and if you really want to live on the edge there's Debian 'experimental' too
20:36:03 * Lakie guesses non-bloated distros are basically the ones with nothing but the very basics, the desktop manager, a few core programs and the kernel.
20:36:07 <DarkED> _ln, lenny may be stable but it's more bleeding edge than etch
20:36:33 <DarkED> Lakie, that is crunchbang in a nutshell. it's built off ubuntu 9.04.1 minimal install with openbox as the wm and pcmanfm as the filemanager
20:36:54 <DarkED> it uses about 130mb of ram at idle for me with just xcompmgr running
20:37:23 <PeterT> Are you running it under Wine?
20:37:30 <DarkED> yes it is. i'm so glad the silverex builds exist for windows
20:37:36 <CIA-4> OpenTTD: alberth * r18464 /trunk/src/build_vehicle_gui.cpp: -Fix (r17863): Caption of the build vehicle window did not have company colours.
20:37:37 <Lakie> why would you run it under wine?
20:37:43 <Lakie> It has native linux builds
20:37:46 <DarkED> yeah xchat is native to linux
20:38:00 <DarkED> PeterT, do sudo apt-get install xchat
20:38:29 <DarkED> the guy who wrote xchat just charges for the windows builds
20:38:37 <glx> official builds are not free for windows
20:38:43 <DarkED> there's a guy called silverex that builds xchat from source for windows, and they are free
20:38:54 <_ln> while otherwise it is GPL
20:38:54 <glx> but as it's GNU anyone can build it
20:39:03 * Lakie used to build his own but got lazy
20:39:19 <DarkED> his builds work perfectly for the most part
20:39:41 <DarkED> silverex's builds are YChat, but XChat is the same project :D
20:40:07 <DarkED> but yeah i love open source in all it's forms
20:40:30 <Eddi|zuHause> <DarkED> the guy who wrote xchat just charges for the windows builds <-- perfect example for free as in speech vs. free as in beer
20:40:36 <Lakie> From a software development point of view, I'm not keen on open source lisencing.
20:40:47 <DarkED> it's not really even about the software being totally free... i'm just happy with the fact that most of it is cross-platform
20:40:51 <DarkED> it makes day to day use easier
20:41:03 <DarkED> Eddi|zuHause, yeah, good point
20:41:13 <glx> it's just because it's a pain to build xchat on windows I guess
20:41:17 <PeterT> DarkED, how did he get the source, then?
20:41:36 <glx> source is available on xchat official site
20:41:38 <DarkED> PeterT, the source is under the GPL and is free to use, build, and modify
20:41:54 <DarkED> PeterT, he only charges for the 'official' xchat windows builds
20:42:07 <DarkED> however, anybody can build an unofficial build for windows and keep it under GPL
20:42:20 <DarkED> thats the beauty of open source
20:42:20 <Lakie> glx: I used to compile it and its quite finical about environment setup and requires soem alterations to code....
20:42:23 <Alberth> Rubidium: oh joy, let's install the most useless Python by default :)
20:42:56 <DarkED> one thing i really cant stand about recent ubuntu releases is that they no longer have libgtk-1.2 in the repos
20:42:57 <glx> Lakie: that's why official builds are not "free" ;)
20:43:00 <DarkED> lots of older games use that
20:43:14 * Lakie has used xchat long before they become not-free.
20:43:22 <DarkED> so for example, to install unreal tournament using loki installer, i have to go hunting for libgtk-1.2 and it's dependencies
20:43:46 <Lakie> I think I read about that on a ut2004 forum.
20:44:11 <DarkED> yeah, ut2004's loki installer uses the same lib iirc
20:44:20 <DarkED> it's a real pain to find that stuff in .deb format
20:44:40 <DarkED> i mean sure, i COULD compile it from source, but sometimes i just want to install and play the stupid game, ykow?
20:44:49 <DarkED> heh... my lack of sleep is killing my typing
20:45:09 <Lakie> You could compile the whole distro from source, but generally we don't want to do that, we want a working OS from the box.
20:45:24 <DarkED> Lakie, this is true but i've been considering it for my desktop lately
20:45:33 <DarkED> linux from scratch has some good info on that
20:45:54 <DarkED> crunchbang is light but i always want lighter
20:46:04 <DarkED> plus it still has that x cpu usage bug on my system
20:46:16 <DarkED> every so often x will start using 100% cpu and i have to restart x to stop it
20:46:44 <DarkED> Rubidium, yeah, but those dont work correctly on ubuntu
20:46:50 <DarkED> you have to use one from an older ubuntu release
20:46:54 <Lakie> The only reason I dropped ubuntu was it crashing with the nvidia drivers for my card...
20:46:55 <DarkED> which are getting harder and harder to find
20:47:14 <DarkED> it's something to do with the way ubuntu has the libs directory structured
20:47:25 <Rubidium> Lakie: the binary-only nvidia/ati are generally crap
20:47:56 <_ln> Rubidium: binary-only nvidia generally works flawlessly.
20:48:09 <Lakie> I must admit I never really looked at the various options for nvidia drivers on linux
20:48:11 <DarkED> _ln, i beg to differ. i've had massive problems in the past
20:48:33 <DarkED> i have had six nvidia cards in the last seven years and the official nvidia binary drivers always have some quirk with them
20:48:57 <fjb> At least on FreeBSd it works flawlessly.
20:49:09 <DarkED> and of course there's only four versions of nvidia linux binary drivers in existence
20:49:10 * Lakie has only had them work fine on openSuse.
20:49:12 <thingwath> even with suspend/resume?
20:49:27 <DarkED> so not many to choose from
20:49:58 <Lakie> I thought some of the open source varients didn't support any form of 3D yet though, which makes them semi-useless.
20:50:01 <Rubidium> fjb: you mean you can run mplayer full screen (1920x1200) without glitches with whatever drivers FreeBSD has?
20:50:43 * fjb only tested with 1280x1024.
20:51:16 <DarkED> Lakie, the neveau nvidia drivers are open source and they support 3D on 8xxx series cards and above
20:51:23 <DarkED> i've heard it is sketchy right now though
20:51:29 <DarkED> but still, they are making progress
20:51:54 <Lakie> Ah right, last time I heard of them, they were still strickly 2d.
20:52:17 <DarkED> they've come a long way since then apparently
20:54:59 <Lakie> The other problem I get is missing libraries or more accurately distros not having new enough versions...
20:55:43 <Lakie> More of a problem when compiling software though, I guess.
20:57:15 *** Eddi|zuHause2 has joined #openttd
20:58:53 *** welshdragon has joined #openttd
20:59:27 <DarkED> im tired... im gonna get some sleep
20:59:59 *** Eddi|zuHause3 has joined #openttd
21:00:14 <Eddi|zuHause3> something's odd with my cable connector
21:00:22 *** Eddi|zuHause3 is now known as Eddi|zuHause2
21:00:52 *** Eddi|zuHause2 is now known as Eddi|zuHause
21:02:16 <Eddi|zuHause> anybody got a spare ~5m cat5 (or better) cable?
21:06:51 * fjb has 20m but wants it back.
21:07:43 * TrueBrain gives Eddi|zuHause 5m cat5e cable
21:08:10 <TrueBrain> I have red, green, and grey
21:08:14 <TrueBrain> also available in 2m, 4m and 10m
21:08:20 <TrueBrain> (oh, and 1m, but they are running low)
21:13:02 <Eddi|zuHause> great, at which time can i get it? :)
21:24:27 <TrueBrain> any time you want; you only need to pick it up :p
21:25:26 <Eddi|zuHause> hm... if i start now, i could be in the city by morning, and in holland by noon ;)
21:25:49 <TrueBrain> so maybe cheaper to go to your local store ;)
21:27:41 *** welshdragon has joined #openttd
21:37:15 *** Rubix`` has joined #openttd
21:53:45 <Eddi|zuHause> few minutes early today?
21:55:53 *** Grelouk has joined #openttd
21:59:49 <edeca> Hrm, does the uk renewal train set include any carriages that can carry cars?
22:02:54 <edeca> Damn it, that was a silly mistake then :)
22:03:19 <fjb> To use George's ECS vectors?
22:04:11 <edeca> There is the "Freightliner Container Rake" in 1972, I don't know whether it carries cars or not (it does carry goods)
22:04:27 <fjb> I'm nor sore UKRS does not support cars, but I don't remember it can. And UKRS is not fully compatible with ECS.
22:05:03 <edeca> I've been using it a few game years and this is the first problem I've had
22:05:10 <CIA-4> OpenTTD: rubidium * r18465 /trunk/src/ (train.h train_cmd.cpp vehicle_cmd.cpp): -Codechange: simplify CheckTrainInDepot and remove some unneeded wrapper functions
22:05:13 <fjb> It is not. UKRS is compatible to PBI.
22:06:05 <edeca> Oh well. This is the first problem I've had. What train sets are more compatible with ECS then?
22:07:27 <Eddi|zuHause> lots of train sets have problems carrying vehicles
22:08:21 <Eddi|zuHause> but i have never heard that UKRS is incompatible to ECS
22:08:24 <fjb> NARS 2 should be compatible with ECS. There is an ECS extension for dbset.
22:08:44 <Eddi|zuHause> the dbset will also not carry vehicles before 1950
22:11:50 <edeca> OK, well I'll bear it in mind if I play again
22:11:57 <edeca> I've got a nice game going
22:14:21 <fjb> Eddi|zuHause: You have the wrong color.
22:14:35 <Eddi|zuHause> yes, blame my cable
22:18:34 * fjb blames Eddi|zuHause's cable.
22:19:46 *** Kami-test has joined #openttd
22:19:49 *** Kami-test has left #openttd
22:21:42 *** Brianetta has joined #openttd
22:24:01 <CIA-4> OpenTTD: rubidium * r18466 /trunk/src/train_cmd.cpp: -Codechange: use CmdMoveRailWagon to attach a just build wagon to a chain
22:28:21 <edeca> Damn the AIs are good now :)
22:30:00 <Rubidium> i.e. use iron ore hoppers and not coal trucks. Also iron ore goes to the steel mill, not the power station.
22:31:10 <fjb> And please use PNG format for OpenTTD screen shots.
22:31:47 <peter1138> also give me lots of money
22:32:15 <edeca> peter1138: Define "lots" :)
22:32:51 * Rubidium presses Alt+1 in the debug build and sends some to peter1138
22:33:03 <Xaroth> Danio: also, distance with maintained speed == more profit
22:33:37 <Xaroth> a net distance of 4 tiles will not yield you much compared to a distance of.. 40
22:34:01 <Xaroth> mainly because your train will be sitting still 90% of it's travel time, the other 10% it'll be accellerating/decelerating(sp?) half the time
22:34:54 <edeca> Right, what's the best way to balance buses so that all 10 of them aren't queuing at once?
22:34:54 <frosch123> that misses a quantifier
22:35:06 <Xaroth> edeca: multiple platforms?
22:35:34 <Rubidium> edeca: timetabling with setting a timetable start date
22:36:14 <edeca> Rubidium: That's the one, thanks
22:36:20 <edeca> I really need to learn how to use timetables
22:36:41 <frosch123> or use fifo loading and timetables with only loading times (no travel times)
22:37:02 <edeca> Ah, timetables have improved since I last used them
22:38:06 <edeca> Is autofill a suitable way to start timetabling?
22:38:15 <peter1138> coo, i have a pop 5 'city'
22:38:24 <peter1138> its sole 'building' is a park...
22:38:46 <frosch123> don't cheat with bulldozers
22:39:11 <peter1138> fresh game with TAI
22:41:40 <Eddi|zuHause> TaI needs influence on town road growth
22:42:03 <Eddi|zuHause> otherwise some cities end up with lots of roads without houses
22:42:25 <edeca> To answer my own question earlier, there _are_ vehicles in UKRS that can transport cars/vehicles
22:43:03 *** Progman has joined #openttd
22:43:43 <edeca> (rail vehicles, that is)
22:43:48 <peter1138> bridges on half-water tiles are hideously expensive
22:44:09 <peter1138> it is about 20 times cheaper to build a longer bridge on flat edges
22:44:58 <Eddi|zuHause> bridges and tunnels are awfully cheap
22:45:25 <edeca> Is it likely that the "leave if another train arrives" option will ever be in the game?
22:46:52 <Eddi|zuHause> i don't see the use for that
22:51:03 <fjb> But bridges on half-water tiles are looking better.
22:53:55 *** DaleStan has joined #openttd
22:55:44 *** DaleStan is now known as Guest1325
22:55:44 *** DaleStan_ has joined #openttd
22:55:45 *** DaleStan_ is now known as DaleStan
22:57:20 *** valhallasw has joined #openttd
22:58:59 *** Coco-Banana-Man has quit IRC
23:00:23 <CIA-4> OpenTTD: peter1138 * r18467 /trunk/src/roadveh_gui.cpp: -Fix (r17870): Missed positioning for cargo capacity of non-articulated road vehicles.
23:22:08 <Eddi|zuHause> why did nobody ever replace "CalcBridgePiece" by a newgrf callback?
23:49:07 <edeca> How do full load & timetables interact? If my train is told to stay in station 10 days, but is full after 1, will it leave?
23:50:17 <Eddi|zuHause> it will leave if both load is full and timetable runs out
23:50:49 <Eddi|zuHause> i.e. it will wait longer, but not shorter than the timetable
23:51:50 <edeca> That makes for interesting planning :)
23:58:53 *** Brianett1 has joined #openttd
continue to next day ⏵
