IRC logs for #openttd on OFTC at 2009-05-23
⏴ go to previous day
00:31:15 *** KenjiE20|LT has joined #openttd
00:44:37 *** Nite_Owl has joined #openttd
01:24:50 *** SineDeviance has joined #openttd
01:26:34 *** SineDeviance has joined #openttd
01:56:34 *** XeryusTC is now known as Xeryus|bnc
02:43:39 *** reldred has joined #openttd
03:12:58 *** TinoDidriksen has joined #openttd
03:31:50 *** SineDeviance has joined #openttd
03:35:12 *** SineDeviance2 has joined #openttd
03:43:09 *** TinoDidriksen has joined #openttd
03:56:46 *** SineDeviance has joined #openttd
04:34:22 *** stuffcorpse has joined #openttd
04:34:24 *** z-MaTRiX has joined #openttd
04:34:38 <z-MaTRiX> encountered a weird thing in OpenTTD
04:35:35 <z-MaTRiX> "unload all, and leave empty" option set, train having 275000 litres of oil after leaving
04:43:44 *** ChanServ sets mode: +v tokai
04:52:45 *** SineDeviance has joined #openttd
05:38:11 *** maristo has joined #openttd
06:19:58 *** Cybertinus has joined #openttd
06:34:08 *** maristo has joined #openttd
07:08:51 *** ctibor_ has joined #openttd
07:11:35 *** Alberth has joined #openttd
07:48:59 *** Hirundo has joined #openttd
08:11:40 *** fonsinchen has joined #openttd
08:17:44 *** |Jeroen| has joined #openttd
08:18:57 *** frosch123 has joined #openttd
08:22:23 <petern> hmm, maybe we need to cull trees a bi more
08:27:03 <petern> frosch123, pikka's fixed the grf now :D
08:27:35 <petern> and it does indeed fix the desyncs, at least so far
08:31:13 *** Progman has joined #openttd
08:47:12 *** dexistin has joined #openttd
09:01:03 *** Azrael- has joined #openttd
09:11:08 <CIA-3> OpenTTD: rubidium * r16394 /trunk/src/ (16 files in 3 dirs): -Codechange: move (NewGRF) cache variables into a separate struct so (some vehicle related) NewGRF cache 'desyncs' can be tested easier.
09:33:13 *** ctibor_ has joined #openttd
09:55:37 *** reldred1 has joined #openttd
10:05:43 *** Xeryus|bnc is now known as XeryusTC
10:24:34 *** Biolunar has joined #openttd
10:35:45 *** dexistin has joined #openttd
10:45:31 *** reldred has joined #openttd
10:53:31 <dexistin> hi, i am trying to figure out what is the best way to replace trains between different types of railways
11:04:05 <dexistin> i tried openttd yesterday after several months, and it lacks only complete graphics/sounds replacement to be perfect :-)
11:08:39 <Ammler> dexistin: use some newgrfs and the replacement is "almost" perfect ;-)
11:10:58 *** KenjiE20 has joined #openttd
11:13:56 <CIA-3> OpenTTD: smatz * r16395 /trunk/src/ai/api/ai_sign.cpp: -Fix (r16379): max sign ID can be higher than total number of signs
11:35:16 <Ammler> possible a grf made on linux or windows wtth the same nfo and same parameters can differ?
11:39:50 <frosch123> you mean because of grfcodec?
11:40:11 <frosch123> then I would guess binary include sprites
11:40:30 <frosch123> grfcodec is quite broken if it comes to them
11:40:51 <Ammler> it seems that comments on the nfo has influence on the grf too, possible?
11:41:07 <frosch123> it reads the filename until it encounters a linebreak. so it keeps trailing whitespace including sometimes \r or not
11:46:11 <planetmaker> well... the solution is to actually use identical nfo build scripts on linux and windows :P
11:47:34 *** Klanticus has joined #openttd
11:47:36 <Ammler> indeed, they make identical grfs now, so it seems fine.
12:05:50 <kkb1101> in ChangeIndustryProduction() function. the variable 'mult' is assigned first and assigned again without being used.
12:06:37 <kkb1101> oh sorry misread actually not
12:08:22 <Alberth> when in doubt, simply highlight all occurrences with the editor search function.
12:13:54 <CIA-3> OpenTTD: rubidium * r16396 /trunk/src/ (11 files): -Codechange: split NewGRF spritegroup into multiple subclasses instead of using a big union
12:27:56 <CIA-3> OpenTTD: rubidium * r16397 /trunk/src/ (8 files in 2 dirs): -Codechange: move GetVehicleOrder/GetLastVehicleOrder into Vehicle
12:42:49 *** Klanticus has joined #openttd
12:45:17 *** yorick_ has joined #openttd
12:56:42 <CIA-3> OpenTTD: rubidium * r16398 /trunk/src/newgrf_spritegroup.h: -Feature: make NewGRF callbacks work again; honouring the 'features' of 0.3.2.1, which was released only 5 years ago.
12:58:04 <yorick> 0.3.2.1 features are building on FreeBSD and MorphOS
12:59:43 *** z-MaTRiX has joined #openttd
13:00:03 <z-MaTRiX> this network is continuously disconnecting
13:09:47 *** Frostregen has joined #openttd
13:14:41 *** yorick_ has joined #openttd
13:15:13 *** yorick is now known as Guest169
13:15:13 *** yorick_ is now known as yorick
13:18:09 * yorick looks at z-MaTRiX' hostname...
13:21:37 <Muxy> Is there a way to make an airport grow automatically ?
13:22:32 <Muxy> programmatically speaking
13:22:33 <yorick> you mean like there's planes, and there's more planes, and then all of a sudden there's a bigger airport?
13:23:01 <Muxy> according to its traffic and quality level
13:23:31 <Alberth> but far from trivial :)
13:23:44 <Muxy> it's a question of time and resources... i know
13:25:33 <Muxy> and of course time... because after plane evolution, there is no solution to use small airports
13:26:38 <Muxy> Yorck: You see what i mean ?
13:29:09 <SmatZ> Muxy: you can use that "Engines never expire" setting
13:29:25 <SmatZ> and helis can use small airports too :-p
13:36:17 *** Singaporekid has joined #openttd
13:41:21 <z-MaTRiX> Eddi|zuHause, all other servers running ok
13:41:52 <z-MaTRiX> Muxy, there is way to make airport grow?
13:42:15 <CIA-3> OpenTTD: frosch * r16399 /trunk/src/newgrf.cpp: -Fix (r4540): Don't treat pointer values as integer.
13:44:03 *** yorick_ has joined #openttd
13:52:26 *** yorick_ is now known as yorick
14:02:50 <Boukev> Was just wondering, is there any database of track layouts or something somewhere online?
14:03:12 <Alberth> the wiki, the openttdcoop wiki
14:06:08 <Boukev> Some great junctions in there :)
14:08:34 *** Brianetta has joined #openttd
14:15:12 *** Klanticus has joined #openttd
14:34:04 *** z-MaTRiX has joined #openttd
14:44:19 *** ctibor_ has joined #openttd
14:45:52 *** |Jeroen| has joined #openttd
14:55:07 <CIA-3> OpenTTD: yexo * r16400 /trunk/ (9 files in 4 dirs): -Add [NoAI]: add AISignList that can be used to get a list of valid signs. This makes AISign::GetMaxSignID obsolete.
15:13:06 *** SineDeviance has joined #openttd
15:23:53 <CIA-3> OpenTTD: yexo * r16401 /trunk/source.list: -Fix (r16400): forgot to commit the changes to source.list (thanks SmatZ)
15:26:04 <CIA-3> OpenTTD: rubidium * r16402 /trunk/src/ (10 files): -Codechange: make Resolve a function of SpriteGroup
15:28:17 *** Hirundo_ has joined #openttd
15:28:17 *** lewymati has joined #openttd
15:33:57 *** Hirundo_ is now known as Hirundo
15:37:05 *** lobstah is now known as lobster
15:42:12 *** dexistin has joined #openttd
15:46:12 <CIA-3> OpenTTD: smatz * r16403 /trunk/ (18 files in 5 dirs): -Codechange: move code related to subsidies to separate file
16:01:28 <z-MaTRiX> only ocean level can contain water?
16:01:59 <z-MaTRiX> (thinking about higher ocean level)
16:02:12 <frosch123> there are canals and rivers
16:02:17 <Eddi|zuHause> there is an old patch doing that
16:03:01 <z-MaTRiX> but unpatched its default right?
16:03:09 *** d3xistin has joined #openttd
16:03:57 <z-MaTRiX> have not seen water at higher levels, was just wondering
16:05:43 <_ln> it's realism. you know water will not stay above sea level in real life either.
16:07:22 *** Dred_furst has joined #openttd
16:07:49 <d3xistin> i guess z-M refers to lakes or maybe even rivers
16:09:38 <d3xistin> just saying it's real, imHo it's absolutely not worth implementing
16:09:58 <_ln> i know... i'm just trying to make Belugas believe it's being realistic now, so he could fix it to unrealistic.
16:10:52 <z-MaTRiX> _ln, well, if you higher the sea edges above sea-level...
16:11:43 <z-MaTRiX> d3xistin, yep that will be a lake
16:12:10 *** d3xistin is now known as dexistin
16:12:16 <Eddi|zuHause> z-MaTRiX: rivers and lakes are already implemented
16:12:39 <Eddi|zuHause> they are just not autogenerated
16:12:51 <Eddi|zuHause> feel free to address that ;)
16:13:14 <Eddi|zuHause> hey, idea: use squirrel for map generation :p
16:13:29 <Yexo> Eddi|zuHause: already done, and it's too slow :)
16:14:01 <z-MaTRiX> "save the trees, eat beavers!"
16:14:33 <dexistin> mm, how can you make a river?
16:14:48 <z-MaTRiX> guessing, map generator
16:15:29 <z-MaTRiX> transport company makes rivers?:)
16:15:53 <yorick> unless ammler has it his way
16:17:39 <Ammler> there is sadly no possibility to make rivers ingame, wrt realism.
16:17:59 <z-MaTRiX> 1000000000 euro should do it :)
16:18:30 <EoD> Has anyone ever tried to compile openttd on sparc (32/64 bit)?
16:19:06 <planetmaker> well, not really, EoD :)
16:19:11 <planetmaker> Give me access and I might try :)
16:19:19 <Alberth> z-MaTRiX: sure, want my bank account number?
16:19:22 <EoD> ok, so i'll post a bug report
16:19:46 <EoD> i'm using openttd on my sparc(/linux) with 32bit userland for a while now, but 64 bit fails to execute
16:20:07 <z-MaTRiX> should į refer to credits ?:)
16:22:31 <planetmaker> any idea why? Sounds like faulty memory access.
16:23:17 *** goodger has joined #openttd
16:23:23 *** DR_Jekyll has joined #openttd
16:23:26 <EoD> no idea so far. I can assure that it don't have faulty memory, it's ECC Ram which is really fine
16:26:02 <EoD> I think it's some combination of (64bit) memory handling and big endian (as it works fine on amd64 and 32bit sparc)
16:28:20 <planetmaker> EoD: I didn't mean to imply that you have faulty memory :)
16:28:39 <planetmaker> I get bus errors, if I programme wrongly and access wrong parts of memory
16:29:28 <EoD> yeah, but bus errors also occur if you have faulty memory. Just wanted to mention that i don't have faulty memory :)
16:29:47 *** HerzogDeXtEr has joined #openttd
16:40:08 <CIA-3> OpenTTD: rubidium * r16404 /trunk/src/newgrf_spritegroup.h:
16:40:08 <CIA-3> OpenTTD: -Fix [FS#2911] (r16378): the number of spritegroups got halved when the new pool was added, which mean there weren't enough spritegroups when you have more than about a dozen ECS vectors.
16:40:08 <CIA-3> OpenTTD: -Change: increase the spritegroup pool's maximum size to something more than the
16:40:08 <CIA-3> OpenTTD: number of real sprites that OpenTTD can handle; for example ECS has about 30
16:40:09 <CIA-3> OpenTTD: spritegroups per real sprite. With the 'old' limit that would mean 'only' about
16:40:09 <CIA-3> OpenTTD: 4000 real sprites worth of spritegroups could be loaded.
16:54:21 <EoD> I'll test sparc64 with some other revisions (without ipv6, without the dynamical memory handling and such things) before i post a bugreport
17:09:52 <Eddi|zuHause> "goes it throw out limitation?"
17:13:37 *** yorick is now known as Guest190
17:17:47 *** theholyduck has joined #openttd
17:22:07 <SmatZ> EoD: I am regularly testing it on sparc/solaris
17:22:52 <SmatZ> EoD: sparc is "sensitive" to unaligned 64bit memory access
17:23:17 <SmatZ> accessing unaligned 64bit ints
17:23:39 <SmatZ> but 32bit are no problem
17:24:24 <_ln> "sensitive" as in it crashes?
17:26:40 <_ln> is that a documented feature of sparc?
17:27:10 <SmatZ> it would be strange not to have this documented
17:27:29 <SmatZ> I think special instruction is used to access 64bit data
17:27:31 <EoD> i had some problems with a dual-pci-x Intel NIC which ended in a bus error, too.
17:27:34 <SmatZ> and it requires them to be aligned
17:27:43 <Alberth> It is not uncommon, the M68000 didn't allow 32 bit value access unaligned.
17:28:31 <SmatZ> actually maybe most architectures require aligned access :)
17:29:54 *** ctibor_ has joined #openttd
17:30:15 <petern> the question is where is it unaligned
17:32:09 *** ChanServ sets mode: +v tokai
17:32:12 <EoD> what exactly does this mean for openttd?
17:32:18 <Eddi|zuHause> SmatZ: but is that than not a bug of the compiler which inserts that instruction in places where it is not safe?
17:33:19 <SmatZ> Eddi|zuHause: the code is breaking the standard
17:33:25 <SmatZ> so it's not compiler bug
17:33:52 <Eddi|zuHause> why would high level language code care about alignment?
17:34:53 <_ln> C++ is not that high-level.
17:35:43 <Eddi|zuHause> anyway, which part is the broken standard then?
17:37:33 <SmatZ> Eddi|zuHause: pointer to type x should be able to access type x
17:37:54 <SmatZ> if the programmer is messing with pointers, it's his fault the code doesn't work
17:39:44 <Eddi|zuHause> that does not explain why the compiler inserts an alignment-critical instruction in places where he cannot guarantee alignment (and thus should insert a non-alignment-critical function)
17:40:45 <Eddi|zuHause> and in places like this languages which allow range checking could be helpful
17:42:34 <_ln> well what should the compiler do if you have e.g.: long long a, *b = a; b += 2;
17:42:39 <SmatZ> it's defined "int64_t" is aligned at 8-byte boundary
17:43:07 <SmatZ> so if you change the pointer so it doesn't point to 8-byte boundary, you will break the code
17:44:45 <Alberth> _ln: that will move b 16 byes (2*sizeof(long long))
17:45:25 <Alberth> You'll need to create an unaligned pointer, then cast it.
17:45:40 <_ln> Alberth: you're right.. what if we assume we had violently casted it to a char*, which i forgot to mention.
17:45:57 <SmatZ> _ln: undefined behaviour
17:46:45 <_ln> hmm, or is the verb "cast, cast, cast"? it probably is. english only.
17:46:47 <Alberth> so a crash is acceptable behavior :)
17:47:51 <SmatZ> A pointer to an object or incomplete type may be converted to a pointer to a different
17:47:53 <SmatZ> object or incomplete type. If the resulting pointer is not correctly aligned57) for the
17:47:54 <SmatZ> pointed-to type, the behavior is undefined.
17:50:27 <EoD> Is there any way i can help?
17:51:44 <SmatZ> EoD: correctly report the problem at bugs.openttd.org , ideally with a way to reproduce and backtrace :)
17:55:11 <Eddi|zuHause> just run a preprocessor that inserts an assert before each dereferencing operation?
17:55:51 <SmatZ> not needed, just gdb bin/openttd ; r ; crash it ; bt full
17:56:28 <EoD> I have a 32bit userland (Sparc/Gentoo), so it isn't that easy to get gdb or at least strace to compile 64bit compatible
17:56:31 <Eddi|zuHause> ./configure --enable-debug=1 && make run-gdb
17:58:36 <EoD> I already tried several ways to get straces compiled with -m64, but it didn't work so farr
18:00:56 <petern> strace is not useful anyway
18:01:17 <EoD> no it isn't, but it's much smaller than gdb ;)
18:06:55 <CIA-3> OpenTTD: alberth * r16405 /trunk/src/widget.cpp: -Codechange: Move widget drawing code to functions to allow re-use.
18:07:31 <SmatZ> EoD: I don't quite understand your problem
18:07:53 <SmatZ> you don't need 64bit system to use 64bit variables
18:08:39 <SmatZ> just install gdb the same way you installed OTTD
18:08:40 <EoD> 32bit gdb works with 64bit files?
18:09:00 <SmatZ> EoD: you are running 64bit OTTD on 32bit system?
18:09:16 <EoD> I'm using a Sparc/Gentoo system which has a 64bit kernel but a 32bit userland
18:09:16 <SmatZ> so why would you need 64bit gdb for that?
18:10:09 <SmatZ> hmm are you mixing 64bit kernel with 32bit glibc?
18:11:12 <EoD> But there someone published some doc to get multilib gcc/glibc on gentoo sparc, which allows to compile 64bit binaries
18:11:18 <EoD> it's a kind of confusing/complicated
18:12:00 <petern> seems kind of pointless
18:12:09 <EoD> read the top and the bottom
18:13:19 <EoD> I'm not really that familiar with sparc architecture in general, but i never heard someone telling me that 64bit userland in sparc is any good
18:13:40 <EoD> except for e.g. mysql, iptables and some similiar applications
18:14:00 <SmatZ> well my guess is the crash is somewhere outside OTTD
18:14:45 <EoD> hmmm. I thought about it, too. But why does ottd crash and my binaries don't?
18:14:57 <petern> so your userland is 32 bit
18:15:03 <petern> and your ottd is 32 bit?
18:15:25 <EoD> my 32bit ottd works just fine, my 64bit ottd doesn't
18:15:54 <EoD> userland is 32bit, except for gcc and glibc
18:16:50 <EoD> so i have to set up some sparc64/debian system to post bug reports about ottd?
18:17:16 <EoD> it's a dedicated version without zlib
18:17:40 <EoD> the sparc is my server/router
18:21:24 <EoD> btw: ottd 0.4 segfaults on sparc64 (no bus error). I'll test ottd 0.5
18:22:07 <EoD> just digging out old versions to be sure no version ever worked on sparc64 :)
18:22:11 <SmatZ> don't care about <0.7 and <r16405
18:22:45 <SmatZ> nobody will fix bugs in 0.4 branch
18:22:51 *** goodger has joined #openttd
18:23:24 <Eddi|zuHause> the possibility of this being a regression is very low
18:25:47 <EoD> Is it possible to debug a 64bit binary with a 32bit gdb (i just read about "multi-arch" at the gdb homepage)?
18:29:23 *** [com]buster has joined #openttd
18:30:36 <petern> you'll just have to try it
18:34:50 *** reldred has joined #openttd
18:37:27 <EoD> i'm afk until gdb finished compiling (~about tomorrow morning)
18:42:16 <Eddi|zuHause> if you have to compile anyway, why not simply compile as 64 bit?
18:46:32 *** Frostregen has joined #openttd
18:47:59 <EoD> then i have to compile ncurses, readline and lzma-utils as 64bit, too. This reduces the change of successful compilation a lot :)
18:48:24 <EoD> I'll try to compile gdb as 64bit if it doesn't work with the 32bit gdb version
18:48:58 <Eddi|zuHause> i have no idea why you go through the whole multiarchitecture trouble anyway
18:52:09 <EoD> to find a way to get openttd sparc64 compatible
19:05:15 <EoD> i think i'm back tomorrow
19:09:24 *** lewymati has joined #openttd
19:14:03 *** fonsinchen has joined #openttd
19:17:58 <DorpsGek> fonsinchen: TrueBrain was last seen in #openttd 1 week, 4 days, 7 hours, 40 minutes, and 17 seconds ago: <TrueBrain> you catched on on that? :)
19:18:16 <planetmaker> both super-admins gone :P
19:18:39 <TinoDidriksen> Email them if you miss them so much?
19:18:39 <planetmaker> taking a well-deserved break, I guess :)
19:19:00 <fonsinchen> I don't have his email address
19:19:11 <planetmaker> well... but you could look them up?
19:19:31 <planetmaker> every dev has an e-mail address here
19:19:41 <planetmaker> dunno though, if they're read :D
19:21:09 <fonsinchen> where would I find that address? And is there anyone else I can talk to about building cargodist on the compile farm?
19:21:44 <PeterT> is there a way to resize a scenario by converting it to a height map?
19:21:50 <planetmaker> fonsinchen: I guess not
19:22:05 <planetmaker> PeterT: not really...
19:22:58 <Eddi|zuHause> fonsinchen: ever tried /msg TrueBrain <blah>?
19:23:14 <Eddi|zuHause> people do not need to be here to be here...
19:23:18 <fonsinchen> no, I didn't know that command
19:23:29 <Alberth> usually people don't like that
19:23:56 <Eddi|zuHause> and for reference, also try /whois TrueBrain
19:24:54 <fonsinchen> He's online actually
19:26:15 <CIA-3> OpenTTD: smatz * r16406 /trunk/src/ (subsidy.cpp subsidy_func.h): -Codechange: constify parameters of CheckSubsidised()
19:28:25 <Ammler> fonsinchen: the dir is up, if you still need a mirror for ;-)
19:32:18 <fonsinchen> I think I'll build my own windows binaries and host them myself until TrueBrain shows up again. Unfortunately I can't give anyone SSH access on that webserver so I might use your server later. Thanks.
19:38:14 <Ammler> truebrain has already access there
19:43:21 <CIA-3> OpenTTD: smatz * r16407 /trunk/src/ (economy.cpp saveload/afterload.cpp station.cpp): -Fix [FS#2913]: set CargoPacket::source to INVALID_STATION when source station is deleted
20:26:15 *** Polygon has joined #openttd
20:49:46 *** tux_mark_5 has joined #openttd
21:10:26 *** Rexxars has joined #openttd
22:19:19 *** duckzor_ has joined #openttd
22:23:42 *** duckzor has joined #openttd
22:24:24 <CIA-3> OpenTTD: frosch * r16408 /trunk/src/newgrf.cpp: -Codechange: Silence a pointless newgrf debug message.
22:40:26 <CIA-3> OpenTTD: rubidium * r16409 /trunk/src/console_gui.cpp: -Change: don't add empty lines/duplicates of the previous command to the console's history
23:32:40 *** KenjiE20|LT has joined #openttd
23:33:22 *** Eddi|zuHause has joined #openttd
23:57:46 *** racetrack has joined #openttd
continue to next day ⏵