Back to Home / #openttd / 2010 / 04 / Prev Day | Next Day
#openttd IRC Logs for 2010-04-02

---Logopened Fri Apr 02 00:00:25 2010
00:10-!-deghosty [] has joined #openttd
00:12-!-bryjen [~bryjen@] has quit [Quit: Leaving]
00:13-!-De_Ghosty [] has quit [Ping timeout: 480 seconds]
00:14-!-De_Ghosty [] has joined #openttd
---Logclosed Fri Apr 02 00:16:32 2010
---Logopened Fri Apr 02 00:16:37 2010
00:16-!-mikegrb [] has joined #openttd
00:16-!-Irssi: #openttd: Total of 107 nicks [5 ops, 0 halfops, 1 voices, 101 normal]
00:17-!-Netsplit <-> quits: Splex, PeterT, FauxFaux, De_Ghosty, sparr, a1270, lobstar, deghosty
00:18-!-Irssi: Join to #openttd was synced in 101 secs
00:28-!-Starn [] has quit [Remote host closed the connection]
00:32-!-De_Ghosty [] has joined #openttd
00:32-!-lobstar [~michielbi@] has joined #openttd
00:32-!-a1270 [] has joined #openttd
00:32-!-FauxFaux [] has joined #openttd
00:32-!-Splex [] has joined #openttd
00:32-!-PeterT [] has joined #openttd
00:32-!-sparr [] has joined #openttd
00:38-!-DDR [~chatzilla@] has joined #openttd
00:54-!-welshdragon [~markmac@] has joined #openttd
01:28<welshdragon>hmm, where can i find out about the changes in 1.0.0?
01:28<welshdragon>i know there are the new base sets
01:29<welshdragon>oh, never mindf
01:29<welshdragon>found the info
02:21-!-Kurimus [] has quit []
02:21-!-Kurimus [] has joined #openttd
02:29-!-Cybertinus [] has joined #openttd
03:17-!-Fuco [] has joined #openttd
03:46-!-ADMINtur [~ADMINtur@] has joined #openttd
03:46-!-ADMINtur [~ADMINtur@] has left #openttd []
03:58-!-Neon [] has joined #openttd
04:19-!-Alberth [] has joined #openttd
04:28-!-Biolunar_ is now known as Biolunar
04:34-!-Progman [] has joined #openttd
04:49-!-devilsadvocate [~devilsadv@] has quit [Ping timeout: 480 seconds]
04:52-!-Terkhen [] has joined #openttd
05:00<DDR>Hi. :)
05:03-!-Zuu [] has joined #openttd
05:09-!-George [~George@] has quit [Ping timeout: 480 seconds]
05:15-!-devilsadvocate [~devilsadv@] has joined #openttd
05:24<andythenorth>does it matter if vehicle bounding boxes are accurately sized (or not)?
05:27-!-ptr [] has joined #openttd
05:31<Alberth>don't know exactly, but I guess: too small -> clipping problems. too big -> possibly draw order problems
05:32<Alberth>but this is an extremely difficult issue, see FS#119
05:34<andythenorth>Alberth: thanks. to template the bounding box for ships....I'll go figure that out.
05:37<planetmaker>andythenorth: if it's a bit too big that's not really a big deal
05:37<andythenorth>and if it's a very lot too big? :P
05:37<planetmaker>Alberth: FS#119 is rather sprite sorting... that issue is also present, if bounding boxes are all exactly to the sprite size, if I understood it correctly
05:38<planetmaker>andythenorth: well... try. My guess is that it's most probably not too problematic. But it depends upon the definition of "too big"?
05:39<andythenorth>well I have two choices: use the same bounding box for most ships (but I have recalculate the xy offsets.....boring), or use defines for the bounding box (lots of defines to set.....boring) :)
05:39<andythenorth>either way....boring :P
05:40<planetmaker>why do you need to re-calculate xy offsets?
05:41<andythenorth>if the bounding box size changes, the xy offs will be wrong.....
05:41<Alberth>Sprite sorting is done based on bounding boxes, non-accurate boxes will not make the issue better. But yeah, FS#119 is much more complex. I wonder if there is even a way to solve it, I fear there is none.
05:41<planetmaker>don't change either, andythenorth. Use the same :-)
05:41<planetmaker>well... yes.
05:41<andythenorth>xy offs are calculated according to center of bounding box (according to wiki spec)
05:42<planetmaker>what's the problem then?
05:42<planetmaker>same bounding box, same offsets
05:42<planetmaker>ship will always be aligned wrt its centre
05:43<andythenorth>problem is the 15 or so ships that already have bounding boxes (different) and offsets
05:43<planetmaker>IF the ship sprites are centred in their templates that is.
05:43<andythenorth>not centered
05:43<planetmaker>that's bad luck then. Happy aligning ;-)
05:43<andythenorth>thanks :P
05:45*andythenorth ponders centering all sprites in the pcx templates
05:45<andythenorth>not a bad idea
05:45*andythenorth wants an apprentic
05:45<planetmaker>that's what is done in OpenGFX and 2cctrainset at least :-)
05:49<planetmaker>hey Zephyris, your 32bpp version of it looks awesome by what I've seen in the forums
05:50-!-Splex [] has quit [Remote host closed the connection]
05:51<Zephyris>Thanks! My little push to a 32bpp future...
05:55-!-Morloth [] has quit [Quit: Lost terminal]
05:56-!-DDR [~chatzilla@] has quit [Remote host closed the connection]
05:57<planetmaker>yeah... it's a nice addition. I'm not too sure about the current implementation of the zoom-levels patch, though...
05:57<blathijs>planetmaker: Makefile.local(.sample) and Makefile.def in opengfx have different opinions about UNIX2DOS's default value
05:57<blathijs>Makefile.local:# UNIX2DOS = $(shell [ `which unix2dos` ] && echo "unix2dos" || echo "cat")
05:58<blathijs>scripts/Makefile.def:UNIX2DOS ?= $(shell [ `which unix2dos 2>/dev/null` ] && echo "unix2dos" || echo "")
05:58<planetmaker>blathijs: Makefile.def is used.
05:58<planetmaker>Obviously I forgot to update the Makefile.local.sample
05:59<blathijs>planetmaker: Yeah, it's not an issue, just a small incosnsitency :-)
05:59<planetmaker>do you need to customize that?
05:59<planetmaker>ah, ok :-) Yeah, thanks for reporting :-)
05:59-!-Splex [] has joined #openttd
05:59<blathijs>I had a local patch for the UNIX2DOS check, but it sems the check was rewritten alltogether, so it should be fine now
06:01<blathijs>But that's why I notifced
06:01<planetmaker>Do you still need a patch wrt unix2dos?
06:03<planetmaker>nice :-)
06:04<blathijs>There used to be a bashism in the use of "type", but you changed to use which, which should work better
06:04<planetmaker>please keep telling me, if / whether you need changes. Better fixing it at the source than each distro separately.
06:04<blathijs>planetmaker: Of course :-)
06:06-!-Zephyris [~Zephyris@] has quit [Quit: Bye]
06:06-!-JVassie [] has joined #openttd
06:06-!-fjb [] has joined #openttd
06:07<blathijs>planetmaker: What's this "Debian support" I see in the changelog?
06:08<planetmaker>that's Debian using nforenum instead of renum as the binary name for... nforenum
06:08<blathijs>Ah, right :-)
06:08<blathijs>I heard about that already
06:08<planetmaker>makes sense in some respect, but not much in other ;-)
06:15-!-snack2 [] has joined #openttd
06:22<blathijs>planetmaker: I guess upstream should just use "nforenum" as well
06:22<blathijs>I mean, the project is even called "nforenum", just not the binary
06:23<planetmaker>blathijs: yes. But there's a difference between 'should' and 'does'.
06:24<planetmaker>I agree, though
06:25<blathijs>But well, it works now :-)
06:25<blathijs>Seems I could build opengfx 0.2.3 without problems, btw (and without local patches :-D)
06:26<blathijs>Haven't tried in a clean chroot yet, because I'm on a crappy connection
06:28<planetmaker>anyway that's good news :-)
06:28<planetmaker>(I don't mean your connection, though)
06:29*andythenorth seriously regrets not centering these ships earlier
06:29<andythenorth>multi-layer photoshop files are not fun to center
06:36<planetmaker>andythenorth: maybe you could create a pcx template like pikka did with the trains
06:36<planetmaker>(or a few for different sizes)
06:36<andythenorth>I was wondering the same thing
06:36<planetmaker>he outlined the acceptable sizes in the templates.
06:37<andythenorth>I don't think it matters for ships....they don't have to line up with each other like trains / aRVs
06:37<planetmaker>well, yes.
06:37<andythenorth>one for trucks is going to be needed though
06:37<planetmaker>I guess the train ones could be used - at least the pcx side
06:37<planetmaker>maybe offsets would need changing
06:37<andythenorth>I wondered that
06:38<andythenorth>project for another day
06:42-!-OwenS [] has joined #openttd
06:43<blathijs>Hmm, make mrproper in opensfx throws away the md5 sums...
06:43<blathijs>Hm, seems opengfx does that as well
06:44<blathijs>planetmaker: Any comments on that?
06:45<planetmaker>well. That's by design
06:45<planetmaker>mrproper should clean everything which is not part of the repository
06:45<planetmaker>such if I'm in my hg repo, it needs to clean that.
06:45<planetmaker>In a source tar ball... well... there it's part of the repo...
06:46<planetmaker>so it's not (yet) designed to work there. But I didn't yet come up with a nice solution which doesn't require to pack a different clean target
06:46<blathijs>I'd expect make mrproper to clean up into a pristine tarball :-)
06:46<planetmaker>or rather on how to do so in a decent way
06:47<planetmaker>yes, understandable with a tar ball :-)
06:47<blathijs>I think "make clean" is usually supposed to clean up what "make" leaves behind, and "make mrproper" should clean up what ./configure creates
06:47<blathijs>But there isn't really a tarball, of course
06:47<planetmaker>well Then clean should clean all.
06:48<blathijs>What are the other files mrproper cleans up?
06:48<planetmaker>as we don't use ./(configure
06:48<planetmaker>mrproper cleans also the dirs created from make bundle*
06:50<planetmaker>clean only cleans everything not created by bundle*
06:51<planetmaker>it's defined in scripts/Makefile.common
06:56<planetmaker>hm, I should possibly consider to provide a ./configure script, too. That might speed up later makefile runs possibly considerably
06:57<blathijs>Hmm, but make install uses bundle* as well, right?
06:57<blathijs>so clean doesn't clean up what make install does?
07:00<planetmaker>not everything. That's true
07:03-!-KenjiE20 [~KenjiE20@] has joined #openttd
07:04<CIA-6>OpenTTD: yexo * r19538 /trunk/src/industry_gui.cpp: -Fix: sorting industries by production was broken for newgrf industries
07:05-!-zodttd2 is now known as zodttd
07:11<blathijs>planetmaker: So perhaps add a third cleaning target, then?
07:11-!-Coco-Banana-Man [] has joined #openttd
07:14<blathijs>planetmaker: Perhaps "distclean" to restore the tarball state?
07:15<planetmaker>I could do that, yes. Is distclean the proper name for that?
07:17<planetmaker>hm... well. why not :-)
07:18<blathijs>dunno, sounds ok
07:19<blathijs>planetmaker: I'll have a patch in a minute, testing it now
07:19-!-Rhamphoryncus [] has quit [Quit: Rhamphoryncus]
07:20<Alberth>but perhaps you want automake targets
07:21<Alberth> :)
07:22<planetmaker>Alberth: I don't use automake. The standard make manual you gave is what I consider my guideline :-)
07:22<planetmaker>though... that gives the same targets :-)
07:23<blathijs>It doesn't define any "repo-clean", rally
07:23<oskari89>Hmm, has anyone done articulated version of long vehicles? For example, the Dolphin bus? :P
07:24<blathijs>planetmaker: What is the $(DIR_BASE)* supposed to clean up? It throws away the MD5 file as well :-)
07:24<planetmaker>blathijs: in principle the mrproper cleans everything which is not repo
07:24<planetmaker>blathijs: yes.... it cleans a lot of generated files and dirs
07:25<planetmaker>they all start with opengfx-<version>
07:26<Alberth>blathijs: last bullit list of kind of says that 'distclean' would be such a target.
07:26<Alberth>but not sure whether 'repo-clean' would be useful in general, ie .pyc files are usually left around in python projects, yet they are not in the repo
07:27<blathijs>Alberth: Even though there isn't really a ./configure, I think ./configure never generates anything which is in the tarball
07:28<blathijs>So distclean shouldn't delete the md5 sums
07:28<Alberth>usually not, indeed afaik
07:28<blathijs>(which are in the tarball, an not the repo)
07:28<blathijs>so we were looking for a name for "repo-clean", that also deletes the sums
07:29<blathijs>planetmaker: but that removes the $(DIR_BASE)*, so that might need to be replaced by a exhaustive list instead?
07:29<planetmaker>blathijs: $(DIR_BASE)* is usually fine
07:30<planetmaker>opengfx-<version>* is always an output of the make process
07:30<blathijs>planetmaker: But that includses opengfx-0.2.3.md5
07:31<Alberth>why not make the md5 sums depend on the file they compute, so they are kept in sync automagically?
07:32<Alberth>ie, why would you want to remove them explicitly? hg up -C or so would take care for such things, wouldn't it?
07:32<planetmaker>Alberth: very bad idea that dependency
07:33<planetmaker>it would mean it's not possible to check for integrity when building from a tar ball.
07:33<planetmaker>Removing that is one of two reasons for 0.2.3 to appear
07:33<Alberth>good point.
07:36*Ammler wonders, what is the point of building it self, if you need to have the same md5sum...
07:37<Alberth>only integrity checking of the data files, probably.
07:38*Alberth wonders whether 'tar' doesn't do that as well.
07:39<planetmaker>Alberth: that=?
07:39<Alberth>integrity checking of the files it creates
07:40<Alberth>ie, it should be able to detect a bad tape block, woudn't it?
07:40<planetmaker>Alberth: sure. But that doesn't check whether you built the same md5sums grfs from the source as I did
07:41<planetmaker>That's the whole point of the supplied *.md5 file
07:41<planetmaker>even if everything got transmitted fine there might be reasons to create a grf with different md5sums - like using old(er) grfcodec / renum or alike
07:41<Ammler>for example the official suse maintainer uses the binary zips
07:42<Alberth>planetmaker: shouldn't the sums be stored with the sources then?
07:42<planetmaker>blathijs: yes... I guess the solution is to name each file / dir separately which needs removing. I'll add that and commit that to the official repo(s)
07:42<planetmaker>Alberth: they are - for source tar balls
07:42<planetmaker>but there's no point to make it a source file in the repo
07:43<Alberth>you store the md5 sums in release tags, I hope
07:44<planetmaker>actually little as it'd change with every nearly every commit and would need updating then and is not needed.
07:44<planetmaker>Alberth: why?
07:44<Ammler>Alberth: in hg, tags are real tags :-)
07:45<planetmaker>Alberth: I pack the md5sums file with the source release. And the official releases contain the md5sums used for the base sets anyway in the base set definition file
07:45<Alberth>so you can reproduce the source tar ball exactly, and verify that you can build the exactly same grf
07:46<planetmaker>Well, the source is released jointly with the md5sum... but yes, not within the repo... Might make sense to note them down somewhere for releases also in the repo
07:46<Ammler>Alberth: doesn't need to be true, if source matches, doesn't mean the final grf will have matching md5sum
07:46-!-DanMacK [~DanMacK@] has joined #openttd
07:46<Ammler>for example, grfcodec is broken with suse factory and there it does produce different grfs
07:46<Alberth>Ammler: we were discussing md5 sums of grf files, or am I mistaken?
07:47<Alberth>then I don't understand "doesn't need to be true, if source matches, doesn't mean the final grf will have matching md5sum"
07:48<planetmaker>Alberth: Ammler you're talking of different things ;-)
07:48<planetmaker>And mean the same :-P
07:48-!-Adambean [] has joined #openttd
07:48<Ammler>you mean, if you build the grf from exact the same source, you should get the same grf, which is wrong.
07:48<planetmaker>Ammler: no he doesn't
07:49<planetmaker>he says that we should note down the md5sums which we want to be created from the source.
07:49<Ammler>how is that possible
07:49<planetmaker>for exactly the reason you state
07:49<Ammler>you need to build the grf to get md5sum
07:50<Alberth>planetmaker: I'd probably even consider them part of the repo, but that is policy
07:50<DanMacK>Hey all
07:50<OwenS>Ammler: You build the GRF and generate the MD5SUM. Users can check against it to ascertain if their grfcodec is working
07:50<Ammler>OwenS: exactly
07:51<planetmaker>OwenS: that's what we do. For source releases.
07:51<Alberth>Ammler: say tomorrow, I have a problem with a version. You just happened to have a disk-crash. All source tar balls are gone. How are you going to verify that I use a sane grf build procedure?
07:52<Alberth>or even, how are you going to reproduce a md5 sum for a old release, after you upgraded to a newer grfcodec?
07:52<Ammler>good point
07:53<Ammler>I think, you can test that with release souces
07:53<Yexo>the md5sum could even be different if one users uses -c (crop extra transparant blue) as option for grfcodec and another does not
07:54<Yexo>although both grfs will be valid they'll still be different
07:54<planetmaker>Yexo: those options are usually set via the Makefile...
07:54<Ammler>the md5sums are also on the nightly available
07:54<Yexo>planetmaker: so if a user overrides some options in makefile.local their build-chain is suddenly 'invalid'?
07:55<planetmaker>If I override build options in OpenTTD I also end up with a different binary
07:55<planetmaker>I see no problem with that
07:55<Priski>why does Openttd randomize its listening port?
07:55<Ammler>the grf might work, but is invalied
07:56<planetmaker>not invalid. Just not a release version
07:56<Ammler>from point of openttd version check
07:56<Yexo>I don't see a problem with that either, as long as you don't try to use the md5 to 'validate' the build-chain
07:56<Yexo>although for grfs you might have a point
07:56<Ammler>Yexo: openttd does that
07:56<planetmaker>Yexo: So: how else, than by a md5sum do you check for whether you built a release version? It's the only way.
07:57<planetmaker>If you do it differently you end up with a grf. But not with the one we released. Quite natural
07:57<Yexo>you're right, I forgot that for newgrfs the md5sum is actually part of their 'version'
07:57<Ammler>but it also helpps us to test builds, for example, I know now, that suse factory has broken grfcodec
08:01<planetmaker>Alberth: in case the whole DevZone would blow up and all copies: the expected md5sums are still available from the files being released. They're the check
08:02-!-Luukland [] has joined #openttd
08:02-!-DanMacK [~DanMacK@] has quit [Read error: Connection reset by peer]
08:02<Ammler>well, maybe we could indeed commit the md5sums of releaes
08:03<Alberth>planetmaker: yep, the problem is only re-constructing a release literally from scratch.
08:04-!-DanMacK [~DanMacK@] has joined #openttd
08:04<Alberth>(perhaps copy the sum from that file while building a release)
08:04<planetmaker>Alberth: I think the solution is to add the md5sums to the readme. That is even half integrated in the makefiles
08:04<planetmaker>then there's no real check, but you have the expected md5sum for every build.
08:05<Luukland>Does the average pause when joining the server takes longer in 1.0.0 than in 0.7.5? Or is it just me?
08:05<PeterT>It's likely just your server
08:05<Alberth>oh, you don't have a special script for building a release? yeah, then the md5sum may not be present.
08:07-!-rubenvincenten [] has joined #openttd
08:07-!-Chruker [] has joined #openttd
08:09<planetmaker>Alberth: not really a special script. The same as for nightlies. Just the tag'ed version
08:10<rubenvincenten>Hey, I have a quick question. I'm running OS X and would like to know which release I have to choose?
08:11<planetmaker>rubenvincenten: you have a problem
08:11<planetmaker>either you use last year's release version or you build it yourself
08:12<rubenvincenten>alright, so I guess I'll need to build it myself then :P
08:12<Ammler>well, why no simply commit the md5sum file like you have?
08:12<PeterT>rubenvincenten: Ok, I'll link you to a guide
08:13<PeterT>stay in IRC while you try to compile, and if you have problems just say so
08:13<rubenvincenten>thanks :)
08:13<PeterT>I can't really help you, since I've only compilied on Linux and Windows
08:14<rubenvincenten>Just to be sure: os x can't use any of the linux packages?
08:14<planetmaker>Ammler: yes, it could be... for releases. But it needs thinking in what form
08:14<planetmaker>rubenvincenten: no.
08:14<planetmaker>it needs OSX ones
08:14<planetmaker>Though the source is the same for all OS
08:17<Ammler>planetmaker: just remove version from the filename
08:18<Ammler>then we update the file with releases and nightlies
08:18-!-fonsinchen [] has joined #openttd
08:19<Ammler>but why do you need to reproduce old releases?
08:19<planetmaker>Not sure whether it's a good idea. How do you "autocommit" that?
08:19<Ammler>you could just test your compile environment with current release
08:20<CIA-6>OpenTTD: terkhen * r19539 /trunk/src/ (build_vehicle_gui.cpp cargotype.h graph_gui.cpp): -Codechange: Use a macro to loop through the list of sorted cargo specifications.
08:24<planetmaker>I don't like the idea to build an md5file for every commit I make
08:25<Ammler>well, I would do it only for releases
08:25-!-lugo [] has joined #openttd
08:26<planetmaker>yeah, that makes sense.
08:26<planetmaker>that's one-time tasks which are managable.
08:26<CIA-6>OpenTTD: terkhen * r19540 /trunk/src/station_gui.cpp: -Feature: Sort the ratings of a station by cargo class / name.
08:26<rubenvincenten>When I compile for OS X, do I have to compile as a universal binary?
08:26<planetmaker>rubenvincenten: no
08:26<PeterT>rubenvincenten: if you are compiling for other people
08:26<planetmaker>as you only compile for yourself you don't
08:26<PeterT>otherwise, no
08:27<PeterT>what planetmaker said
08:27<planetmaker>usually you don't want that. It doubles or tripples your compile time
08:27<planetmaker>just do a ./configure && make and (hopefully) you're fine
08:28<CIA-6>OpenTTD: terkhen * r19541 /trunk/src/vehicle_gui.cpp: -Feature: Sort the list of refit options by cargo class / name.
08:28<planetmaker>feature-itis - day :-)
08:28<rubenvincenten>Hmm, getting something about liblzo2 not found
08:29<PeterT>you have two options
08:29<PeterT>get liblzo2, or ./configure --without-liblzo2
08:29*PeterT thinks that's the correct option, but is not sure
08:30-!-valhallasw [] has joined #openttd
08:31<PeterT>planetmaker would know where to get it
08:31<planetmaker>either from the official website or via macports
08:31<planetmaker>rubenvincenten: also: you need not necessarily worry about liblzo2
08:32<PeterT> says that even "Fink" works
08:33-!-glx [glx@2a01:e35:2f59:c7c0:7978:eeba:93a2:315] has joined #openttd
08:33-!-mode/#openttd [+v glx] by ChanServ
08:33<PeterT>glx: IPv6 hostnames are funny-looking
08:34<SpComb>you're funny-looking
08:34<SpComb>IPv6 hostnames look exactly the same as IPv4 hostnames
08:34<PeterT>Your logic is flawed since you haven't met me
08:36<Alberth>did you meet that IP address?
08:37<rubenvincenten>Hmm, compiling stuff is fun
08:38<PeterT>is it really?
08:38<PeterT>Alberth: you got me there
08:41<rubenvincenten>hmm, lzo/lzo1x.h: not found, then lzo_version)string not declared in this scope
08:41<rubenvincenten>guess I need to install lzo 1 also then
08:46-!-Goulp [] has quit [Ping timeout: 480 seconds]
08:48<rubenvincenten>petert: I installed both lzo and lzo2 using macports, however make reports crashlog.cpp can't find lzo/lzo1x.h, do I need to symlink to the macports path of lzo?
08:48<PeterT>please, ask planetmaker
08:48<PeterT>I don't know Mac stuff
08:48<PeterT>I just (vaguely) know libllzo2
08:48-!-Muxy [] has quit [Ping timeout: 480 seconds]
08:51-!-ajmiles [] has joined #openttd
08:51<Eddi|zuHause>likely the ./configure script needs updating so that it searches in the macports path
08:53<Ammler>rubenvincenten: afaik, you need lzo only for old saves, so just compile without
08:53<Ammler>and fiddle with lzo, if you really need it
08:54<andythenorth>rubenvincenten: hmmm....I can compile trunk for Mac without lzo right now. Dunno why
08:54<rubenvincenten>well I do have some old saves, so I like to do it the right way
08:54<andythenorth>I have lzo via macports, but AFAIK it's not in the search path (it never worked previously)
08:54-!-davis [] has joined #openttd
08:55*andythenorth compiles now to see Terkhen's sorting feature :)
08:55<Ammler>rubenvincenten: ttd saves...
08:55<PeterT>andythenorth: you could be the mac developer
08:55<PeterT>andythenorth: you have the will power
08:55<blathijs>planetmaker: Sorry, my battery was empty. I'd be grateful if you could get that patch up soon, then I can use it in the 0.2.3 Debian package as well (No need to do a release just for this, I guess)
08:56-!-Wizzleby [] has quit [Remote host closed the connection]
08:56<Ammler>we need him to develop grphics :-P
08:56<andythenorth>PeterT: what Ammler said
08:56<andythenorth>I'm busy making graphics all the hours I'm allowed to be :P
08:57<andythenorth>plus, I'm a hacker not a programmer
08:58<planetmaker>blathijs: yes, it's on my list. But the next release will take a bit ... and probably is 0.3 then :-)
08:58<planetmaker>But expect to find it in some of the next nightlies. Just now I need to go out shoot some photos ;-)
08:58*andythenorth is somewhat underwhelmed by the bros april fools joke :P
09:02<rubenvincenten>now I'm getting something about "_FILE_OFFSET_BITS" is not defined
09:02<andythenorth>OS X version?
09:03<andythenorth>you might need planetmaker to help
09:03<andythenorth>I'm using leopard
09:04<rubenvincenten>also, stuff like /opt/local/include/lzo/lzodefs.h:434:6: warning: "LZO_OS_DOS16" is not defined
09:04-!-ajmiles2 [] has joined #openttd
09:04-!-Wizzleby [] has joined #openttd
09:05<planetmaker>rubenvincenten: I do get that, too. It surfaced with my last update of some things at macports
09:05<planetmaker>it's also not critical. Albeit not nice.
09:05<blathijs>planetmaker: In a nightly is fine, I'll just backport the patch
09:05<planetmaker>blathijs: why backport? Do you need that for a release?
09:05<rubenvincenten>planetmaker: figured that, just checking to be sure.
09:06<andythenorth>is this related?
09:06<planetmaker>rubenvincenten: I *think* it's a macports issue. One might consider to file a bug report there.
09:06<blathijs>planetmaker: It sorta breaks my build (it cleans before it builds, so the md5 check doesn't happen)
09:07<blathijs>planetmaker: I could also just use "make clean" for now, some extra clutter isn't really a problem
09:07<planetmaker>blathijs: but clean doesn't remove the md5
09:07<blathijs>planetmaker: I'm calling mrproper now
09:07<planetmaker>ah. ok
09:08<blathijs>But I guess I'll just use make clean for now, so no hurry :-)
09:09<rubenvincenten>andythenorth: Yeah I googled that topic, my config command was ./configure --with-liblzo2=/opt/local/lib/liblzo2.a --CFLAGS=-I/opt/local/include
09:09<rubenvincenten> as well
09:10<andythenorth>how do I find out if my compile used liblzo2?
09:10<andythenorth>Terkhen: cargo sorting == win
09:10<andythenorth>way more useable
09:10-!-ajmiles [] has quit [Ping timeout: 480 seconds]
09:10<andythenorth>now just to show the cargo icons in lists...
09:13-!-aber [] has joined #openttd
09:14<Alberth>andythenorth: does ldd openttd work?
09:14<Alberth>s/ w/ w/ :)
09:15<Alberth>ldd should display the libraries it dynamically loads
09:17<Wizzleby>I always find the output of lddtree a bit easier to grok though
09:18<OwenS>Many systems don't have lddtree
09:19<Eddi|zuHause>that's what ldd tells me: => /usr/lib/ (0xb7d37000)
09:19<OwenS>Incidentally, I wonder why /opt/sunstudio12.1/bin/CC links to
09:20<Eddi|zuHause>what package is lddtree in?
09:20<blathijs>planetmaker: The same problem also applies to opensfx, btw. Can you fix that as well, or should I bug somebody else about that?
09:21-!-Luukland [] has left #openttd []
09:21<Eddi|zuHause>blathijs: i'm fairly sure he's the right person to bug :)
09:21<blathijs>Eddi|zuHause: Good :-)
09:21<blathijs>Saves me explaining everything to somebody else as well :-p
09:22<blathijs>planetmaker: Ah, now I'm using "make clean", and "make check" gets run properly it seems :-)
09:22<OwenS>Eddi|zuHause: I imagine, if it exists, its in SUNWlddtree ;-)
09:23<rubenvincenten>hmm, now I wonder where I should install opensfx, as installing to the shared dir (/library/application support/openttd/data) doesn't seem to work
09:23<blathijs>Yup, if I change an nfo file, I get a checksum mismatch
09:23<blathijs>so it really works :-p
09:31<OwenS>Hmm... Since when was the OpenTTD toolbar centered?
09:31<Yexo>there is a setting for that
09:31<Ammler>compile warnings: (nightly)
09:31<Yexo>I think the default was changed to centered between 0.7 and 1.0
09:31<Yexo>Ammler: those are invalid
09:32<OwenS>Aah, so my config is still left, but the new install on the OpenSolaris box is defaulting to centered
09:32<Yexo>gcc 4.0?
09:33<Ammler>gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
09:35<Ammler>ok, thanks and sorry :-)
09:45<OwenS>Hmm... Does OpenTTD's blitter ever read what it has written to the screen?
09:46<OwenS>(The 8bpp one that is)
09:48<OwenS>(The reason is that I'm pondering an 8bpp-opengl blitter, and if it does any readback is rather important)
09:52<blathijs>I think there have been a few attempts at OpenGL blitters before, IIRC there were problems with that
09:52<blathijs>But it might be that the entire blitter-thing has been restructured since then
09:53<OwenS>blathijs: Most of them use OpenGL to do the drawing. I'm considering just splatting the image straight into VRAM and then asking OpenGL to render that to the framebuffer
09:53<OwenS>Primarily for hardware without hardware 8bpp support (Emulating it using a fragment shader)
09:54<rubenvincenten>Hmm I seem to be missing the option to show a station's reach (to see what the best placement is)
09:56<Alberth>in the station picker window you can toggle the rectangle (just above the cargoes)
10:03<Alberth>hmm, it is so basic, our wiki doesn't even mention this
10:08<planetmaker>[15:20] <blathijs> planetmaker: The same problem also applies to opensfx, btw. Can you fix that as well, or should I bug somebody else about that? <-- basically I'm to blame for virtually any grf-related makefile currently found on the DevZone ;-) so yes.
10:08<planetmaker>they all more or less share the same basic makefile
10:09<planetmaker>hopefully actually "more" :-)
10:10<Zuu>If a cargo has town effect NONE, can there still be town houses (=buildings that do not show up in AIInudstryList) that accept this cargo?
10:11<Zuu>So you actually has to make a tile list over each town and see if they accept a given cargo or not without being able to filter out eg wood by a simple api call?
10:11<CIA-6>OpenTTD: terkhen * r19542 /trunk/src/ (graph_gui.cpp lang/english.txt): -Feature: Add buttons to enable / disable all cargos at the cargo payment rates graph.
10:11<Yexo>Zuu: yes
10:12<Zuu>If eg FIRS contain a market place that accept food in temperate I would guess it would show up in the industry list, but then acording to your answers FIRS could add new town buildings that accept food in temparet if it wanted to do so.
10:12<Yexo>would something like bool AICargo::IsAcceptedBYSomeHouse(CargoID) be useful?
10:12-!-fjb [] has quit [Read error: Connection reset by peer]
10:13<planetmaker>Zuu: houses can accept any carge the newgrf author wishes
10:13<Alberth>wouldn't you have to find a place for it anyway?
10:13<planetmaker>today is my typo day
10:13<Alberth>s/it/a station/
10:13<Yexo>Alberth: yes, but if you know no house accepts a cargo you don't have to scan towns for it
10:13<Yexo>if there is at least one housetype that accepts that cargo, then you'll have to scan all towns for a suitable location
10:14<Zuu>well, yes you will have to make a tile list for mail, passengers, goods etc. and see how well it is accepted but if there is 64 cargos you could be happy to not have to check that for every cargo.
10:14<blathijs>planetmaker: Thanks! :-)
10:14-!-fjb [] has joined #openttd
10:14<Alberth>then make perhaps it more useful and return a search area?
10:14<Yexo>Alberth: what kind of search area?
10:14<planetmaker>blathijs: generally, if something doesn't work (or works) for one project, chances are very good it's the same for the other
10:14<Alberth>for a place to put the station down
10:15<Yexo>that is up to the AI, not the API
10:15<Yexo>besides, what kind of area would you return for normal passengers? a disjoint set over all towns on the map?
10:15<Zuu>Also, many AIs would check many towns/industries before deciding which pair to connect, and only then really care about finding a location for the station.
10:16<Alberth>sure, but if we are to search the town, why not give an area where it is useful to look for placing a station?
10:16<Yexo>Alberth: I wasn't suggesting to search the town
10:16<Yexo>only looping over all house types
10:16<Yexo>searching a town would mean looping over the complete map I think
10:17<Zuu>If you ahead know that a cargo that you found being produced at an industry is never accepted by any towns, then you don't have to search for towns for that cargo from that industry.
10:18<Alberth>the question is , what happens when you do have a matching cargo
10:18<Yexo>then you'll have to search for a good location anyway, just like you have to now
10:18<Zuu>Then I wolud have to scan towns that are close enough to be intresting and see if they accept the cargo.
10:18<Alberth>'scan towns' is the whole map, it seems
10:19<Yexo>most AIs limit the region to center of town +- 20,20
10:19<Yexo>or a similar value depending on the town size
10:19-!-PeterT_ [] has joined #openttd
10:21<Eddi|zuHause>Zuu: but humans also don't check the whole map
10:21<Eddi|zuHause>they first check all industry types, and then all house types
10:21<Alberth>so the answer from the new api call is not the same as what AIs do next
10:22<Yexo>indeed, it's only an optimization so AIs know they can skip the next step
10:23<Zuu>As AIs can't neither read the NewGRF manual or look at the graphics to get such clues.
10:36-!-KillaloT [] has joined #openttd
10:38-!-George [~George@] has joined #openttd
10:39-!-Tennel [] has joined #openttd
10:45<Eddi|zuHause>that's the entire core of the problems: newgrfs have no measures to give hints to ais
10:47<+glx>theorically there are callbacks for that, but IIRC not very usable for NoAI
10:48<OwenS>O_o... The Qt git repository has doubled in size since the year it was created (or, rather, split off from the qt-history repository)
10:48<Yexo>only cb I know of is cb 18, which is only for building engines / stations
10:49<Yexo>* only ai-related callback
10:49<OwenS>**since it was created last year
10:49<+glx>Yexo: as I said not very usable ;)
10:55<Yexo>can someone check this (it's about action4):
10:58-!-PeterT_ [] has quit [Quit: Leaving]
11:06<Zuu>Hmm, after having with AITile.GetCargoAcceptance() found out that say the 21x21 tiles around the town center accept a cargo. How do I make sure that there isn't an industry in the town that caused it to accept the cargo? I can't seem to find a way to find out if a given tile contains an industry or not.
11:07<Zuu>Apart from looping over all industries and hope that there is a AITileList_Industry class.
11:09<Yexo>I think there is no way
11:09<Yexo>there is no AITileList_Industry class either
11:09<Yexo>so it's completely impossible I think
11:10<Eddi|zuHause>why does that even matter?
11:11<Yexo>it it's accepted by an industry you can keep track of that industry and close down the route when that industry closes
11:11<Yexo>if it's part of a town you'll have to check regurarly if the station still accepts the cargo
11:11<Zuu>And town and indistries use different API calls, so it is quite important to keep track of.
11:11<Eddi|zuHause>so you need something like "get all industries in catchment area"
11:12<Zuu>Yep, that would be awsome.
11:13<Zuu>Or even AIIndustry.GetIndustryID(tile)
11:13<Zuu>Similar to the AIStation.GetStationID(tile)
11:15<planetmaker>~/Documents/OpenTTD/content_download/ai> tar tf NoCAB-2.0.0.tar
11:15<planetmaker>tar: Truncated input file (need to skip 1536 bytes)
11:15<planetmaker>tar: Error exit delayed from previous errors.
11:15<planetmaker>any idea as of the reasons?
11:15<planetmaker>also a re-download won't change that
11:16<planetmaker>might my mirror have a truncated file?
11:16<planetmaker>also: re-download is always possible... I won't get a green bullet there
11:16<Yexo>then delete the old file
11:16<Yexo>after that try redownload again
11:17-!-ADMINtur [~ADMINtur@] has joined #openttd
11:17-!-ADMINtur [~ADMINtur@] has quit []
11:17<Yexo>$ md5sum NoCAB-2.0.0.tar
11:17<Yexo>7a0240def16cca9c147457d54291afe3 *NoCAB-2.0.0.tar
11:19<OwenS>OpenSolaris' extended file attributes are insane
11:19<planetmaker>Yexo: a re-download shows the same problem.
11:19<planetmaker>also after deleting the previous 2.0.0 version
11:19<Zuu>Yexo: If you get some time over some day maybe you can take a look at the break on string patch for NoAI? I haven't compiled it for a while but back then when I posted the last version it was quite ready. I'll try to compile it some day and see if it needs to be updated due to changes in trunk.
11:20<OwenS>Each file has a logical directory associated with it. Each such directory can contain files, directories, and files with their own attributes as you wish
11:20<Yexo>planetmaker: does the md5sum match the one above?
11:20<Yexo>Zuu: which FS# was it again? I'll take a look at it today
11:32-!-Dred_furst [] has joined #openttd
11:33<PeterT>BaNaNaS is unually slow
11:33-!-Biolunar [] has quit [Ping timeout: 480 seconds]
11:34-!-|Jeroen| [] has joined #openttd
11:36<PeterT>can we make the sound for laying track in osfx a bit louder?
11:36<PeterT>in fact, many osfx sounds are quiet
11:37-!-KillaloT [] has quit [Quit: HydraIRC -> <- IRC has never been so good]
11:37<planetmaker>PeterT: it can be made. *someone* has to do that, though
11:37<planetmaker>But I see no sound artist with a passion around. Nor have I seen
11:44<Zuu>Regarding cargo, I'll for now use a hack with a list containing safe cargos that towns accept and another list containing cargos that towns produce. This lists I'll probably be able to fill with PAX, mail, goods, water etc.
11:47<welshdragon>planetmaker: passion isn't needed, somebody just needs to use Adobe Audition or something to make it louder
11:48-!-tokai|mdlx [] has quit [Quit: c('~' )o]
11:48<Yexo>Zuu: water isn't accepted by houses normally
11:48<planetmaker>yes. But *somebody* needs some passion in order to actually be the 2nd person in order to start meddling with sounds for OpenTTD
11:48<Yexo>in the desert climate it's accepted by water towers (=an industry)
11:49<Zuu>oh, yea total mind loss :-)
11:52<Eddi|zuHause>MB once said he has a house set that accepts coal
11:52<planetmaker>unless again someone defines houses which accept it ;-)
11:52<Eddi|zuHause>(and shows smoke animation if coal was delivered recently)
11:53<planetmaker>it will be released right after dbxl 1.0
11:59-!-TheMask96 [martijn@] has quit [Ping timeout: 480 seconds]
12:02<planetmaker>hm... any way to find out which bananas mirror I use?
12:03-!-tokai [] has joined #openttd
12:03-!-mode/#openttd [+v tokai] by ChanServ
12:06-!-Adambean [] has quit [Read error: Connection reset by peer]
12:06-!-TheMask96 [] has joined #openttd
12:07<@peter1138>heh, 1.0.0 release certainly increased traffic somewhat
12:09-!-JVassie [] has quit [Ping timeout: 480 seconds]
12:14-!-davis [] has quit [Ping timeout: 480 seconds]
12:15<Eddi|zuHause>planetmaker: look how redirects you?
12:15<Eddi|zuHause>assuming the load balancing mechanism works the same way
12:16<planetmaker>good point
12:16<planetmaker>hm... NoCAB isn't yet synced...
12:17-!-Grelouk [~Grelouk@] has joined #openttd
12:17<planetmaker>do you get a working download of NoCAB 2.0.0? I assume so...
12:19<Eddi|zuHause>i have no idea
12:20-!-heffer [] has joined #openttd
12:26-!-Splex [] has quit [Ping timeout: 480 seconds]
12:34-!-Splex [] has joined #openttd
12:38<Terkhen>planetmaker: I downloaded NoCAB 2.0.0 two hours ago
12:38<planetmaker>I assume no problems, eh?
12:39<Terkhen>none, it works fine
12:41<planetmaker>hm. The version from the forums works fine for me, too
12:43-!-Biolunar [] has joined #openttd
12:44-!-Progman [] has quit [Remote host closed the connection]
12:44-!-Lakie [~Lakie@] has joined #openttd
12:46<CIA-6>OpenTTD: terkhen * r19543 /trunk/src/graph_gui.cpp: -Feature [FS#3726]: Scale the vertical axis of graphs depending on the graph's highest value.
12:46*andythenorth stares glumly at some very wrong offsets for ships :|
12:48<planetmaker>o/ graph scaling!
12:48<planetmaker>Terkhen likes features ;-)
12:51<Terkhen>it is really a mix of feature and fix
12:52<Eddi|zuHause>somehow my antenna is slightly misaligned
12:53<Eddi|zuHause>i get small but annoying image errors in my night recordings
12:53<Eddi|zuHause>during the day it's fine, apparently
12:53<Terkhen>I have finished for now... time to test :)
12:58-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
12:59-!-fonsinchen [] has joined #openttd
13:03-!-yarikos [~yarik@] has joined #openttd
13:04<yarikos>i've got 1.0 dmg for osx 10.5. anybody interested?
13:07<Zuu>planetmaker: I downloaded NoCAB yesterday I think (or if it was this morning)
13:08<planetmaker>ok, so it's really me.
13:08<Zuu>Or it is NL
13:09<planetmaker>who knows. But the mirror doesn't have it, if I look at
13:09<planetmaker>so we all should get it from the main server
13:14<planetmaker>yarikos: you could post it in tt-forums...
13:17<yarikos>does it requires a kind if registration?
13:17<planetmaker>as any forums
13:17<planetmaker>besides compilation is not the issue the macport has.
13:17-!-enr1x [~kiike@] has joined #openttd
13:20<planetmaker>hm... universal compile takes ages :-P
13:20<yarikos>i've taken svn tags/1.0.0 - it compiled without any troubles (i didn't try the universal build)
13:21<planetmaker>he... I cannot produce them.... linker failure.
13:21<yarikos>btw, does anybody still need lzo2 support? i've compiled without it
13:21<planetmaker>I don't have universal libraries
13:22<planetmaker>some probably.
13:23<planetmaker>possibly the trunk intro savegame
13:23<yarikos>miniLZO is not enought, is it?
13:25<Eddi|zuHause>yarikos: it used to use minilzo, but that caused too many maintenance troubles
13:25<aber>what looks the start screen like without lzo2, just water?
13:26<Eddi|zuHause>aber: the 1.0.0 start screen is a new savegame, it should not be affected
13:26<yarikos>with opengfx the start game is o.k.
13:26<planetmaker>of the 1.0 branch. That's another start game than trunk has
13:26<Eddi|zuHause>i don't know if the old one is...
13:26<yarikos>me either
13:27<planetmaker>Also the graphics set used has no influence on whether a game can be loaded... at least it should :-)
13:27<yarikos>then, it is o.k. as for 1.0
13:27-!-ccfreak2k [] has quit [Killed (NickServ (Too many failed password attempts.))]
13:27-!-ccfreak2k [] has joined #openttd
13:28<planetmaker>Well. Using 1.0 doesn't mean one doesn't try to load an old savegame
13:28<planetmaker>But ... in 99.95% it shouldn't matter
13:28<yarikos>i'm already building liblzo
13:29<planetmaker>seems like the bigger challange is anyway to get all those required libs as universal libs
13:30<planetmaker>liblzo2, libpng, libfreetype, libicu*
13:31<aber>you should use boost, then its like a 24h burn in test...
13:31<aber>libicu is broken, at least for me...
13:34-!-Biolunar [] has quit [Read error: Operation timed out]
13:34<planetmaker>define 'broken' :-)
13:35-!-tdev [] has joined #openttd
13:35<CIA-6>OpenTTD: yexo * r19544 /trunk/src/ (7 files in 3 dirs): -Feature [FS#3496]: add an input box to the AI Debug window where you can input a break string (patch by Zuu)
13:35<aber>+universal (i386 x86_64 ppc) does not install
13:35<Yexo>Zuu: some comments: don't use DoCommand from gui code, use DoCommandP instead (or it'll break in multiplayer)
13:36<Yexo>only place pause mode is changed is in CmdPause
13:36<Zuu>Okay. IIRC I was fiddling around with both DoCommand and DoCommandP until I got something that worked.
13:37<Zuu>Thanks for taking your time to get it in.
13:37<Yexo>thanks for the nice patch :)
13:37<yarikos>src/crashlog.cpp:167:23: error: lzo/lzo1x.h: No such file or directory
13:38<yarikos>(JFYI, i'm working it around)
13:38-!-|Jeroen| [] has quit [Quit: oO]
13:41<yarikos>(sorry for noise?)
13:42-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
13:42<Zuu>Yexo: I found a typo in one comment of the code that you commited, probably my fault "matchding" should of course be "matching".
13:42-!-Alberth1 [] has joined #openttd
13:42-!-Alberth is now known as Guest1054
13:42-!-Alberth1 is now known as Alberth
13:43<Zuu>it is in ai_gui.cpp
13:43<CIA-6>OpenTTD: yexo * r19545 /trunk/src/ai/ai_gui.cpp: -Fix (r19544): typo
13:43<Yexo>I added those comments, it wasn't your fault
13:44<yarikos>shouldn't 3rd party libs find its way to ottd sources so there would be no need to pull threads from the world
13:45<CIA-6>OpenTTD: translators * r19546 /trunk/src/lang/ (french.txt korean.txt spanish.txt):
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: french - 4 changes by glx
13:45<CIA-6>OpenTTD: korean - 2 changes by junho2813
13:45<CIA-6>OpenTTD: spanish - 5 changes by Terkhen
13:45<planetmaker>yarikos: why should 3rd - party stuff in the openttd repo, if it can be pulled from their original source?
13:46*Alberth consider adding X11 source code
13:46<planetmaker>it would be nice to have that in an SDK, though :-)
13:46<planetmaker>but then... that would need maintenance. And building static binaries. Not necessarily good.
13:47<Alberth>most linuxes have a packagemanager that can install the 3rd-party libs, if it didn't already do so when installing the OS.
13:47<yarikos>what's bad with static linking at least against -licu -lpng -llzo2?
13:47<planetmaker>bigger binaries
13:48<Alberth>how is that helping you in building a binary yourself?
13:48<planetmaker>add to that doing that 3 times for universal ones.
13:48<aber>4..5.. :)
13:48-!-Guest1054 [] has quit [Ping timeout: 480 seconds]
13:49<planetmaker>aber: the usual universal binaries have intel, ppc and ppc-g5
13:49<aber>no amd64 *buhuuu*...
13:50-!-hron84 [] has joined #openttd
13:50<Zuu>doesn't the intel work on amd64?
13:50<+glx>planetmaker: they can have ppc64 and x86_64 too
13:50<yarikos>i would't like to start another dynamic-vs-static wars here
13:51<planetmaker>right :-)
13:51<hron84>Hi, I ran to exactly this issue: Is there any solution?
13:51-!-fonsinchen [] has joined #openttd
13:51<+glx>hron84: udpate ?
13:51<yarikos>however, i came from plan9 world were we depend on just one thing in runtime: the kernel
13:51<hron84>after i start openttd that message appears
13:51<planetmaker>hron84: update. Both OpenTTD and AI
13:52<Zuu>hron84: What OpenTTD version do you run?
13:52<+glx>1.0.0 is out
13:52<Zuu>0.7.5 should work also I think
13:52<hron84>but it masked under gentoo
13:52<planetmaker>hron84: so? Just download the binary and run it in your user dir.
13:52<yarikos>any hints on getting liblzo compiled universal?
13:53<Zuu>hron84: Do gentoo allow you to upgrade to 0.7.5 (or 0.7.4)?
13:53<planetmaker>yarikos: no idea. I just looked myself
13:53<yarikos>should we bother with universal at all?
13:53<hron84>Zuu: wait, i update package infos, i hope 0.7.5 is placed under stable arch
13:53<Zuu>0.7.5 should be ok to solve your problems.
13:53<+glx>I had no problems to compile macports liblzo2 IIRC
13:54<+glx><yarikos> should we bother with universal at all? <-- yes
13:54<hron84>but my network is little slowy
13:54<Zuu>Still I wolud rather upgrade to 1.0.0 and have all the last features :-)
13:54<planetmaker>yarikos: well... that does make sense. But actually only when one tries to fix all OSX bugs
13:54<+glx>many OSX users don't now the type of their CPU
13:55<yarikos>glx: true. most time it's idling
13:55<Zuu>hron84: too slow for a 3-4 MB binary?
13:56<hron84>not, slow for update my gentoo package infos
13:56<Zuu>or get the 1.0.0 sources of I don't know how big they are.
13:56<hron84>i don't like install anything out of package manager
13:56<hron84>if it not neccessary
13:56<+glx>it's not an install, it's just an extract in home dir
13:56<Zuu>You don't need to install OpenTTD in /usr, you could install it in your home dir as glx just said.
13:57<planetmaker>not even install actually. Just unzip
13:57<+glx>planetmaker: you're slow ;)
13:57<Zuu>Since there is (most likely) nothing in portage that depends on OpenTTD there is not much of a problem to not use portage to get it.
13:57<hron84>and the closed files are still needed?
13:58<Zuu>Not for 1.0.0
13:58<Zuu>If you refer to the TTD data files.
13:58<planetmaker>Haven't been really for 0.7.x neither...
13:58<hron84>btw, is there a 64 bit binary?
13:58<Zuu>Indeed you could play 0.7.x soundless with the free graphics.
13:59<planetmaker>hron84: just visit the download location...
13:59<Zuu>Indeed, see the Linux Generic Binaries.
13:59<Zuu>There you have x86_64, 64bit
14:01<+glx>and generic are statically linked I think
14:01<Zuu>Please add a note to your forum post on that forum that upgrading to 0.7.5 would solve your issue. And possible also a note that 1.0.0 is out.
14:01<yarikos>seems i have to kill liblzo sources and get it installed via macports (which i have to have installed before)
14:03<yarikos>no, thanks, that's too much for my 3G carried data plan
14:04<yarikos>so I'll make intel-only but with lzo
14:05<planetmaker>yarikos: if you have the liblzo sources you can install them manually, too.
14:05<planetmaker>Just producing universal libs... is difficult :-)
14:06<planetmaker>but then... macports is easy
14:06-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
14:07<yarikos>planetmaker: i've got the sources. still, i don't see what and where to do to make it universal
14:07<planetmaker>yarikos: yes, me neither. But if you worry about your download plan, you could install from that source
14:07<planetmaker>a non-universal one
14:08<yarikos>that's what i'm doing.
14:09<yarikos>which libicu to pick up?
14:10<yarikos>15M lib? what did they put in there?
14:10-!-Zephyris [~Zephyris@] has joined #openttd
14:11<yarikos>i'll try with icu4c 4.4
14:12<PeterT>Zuu: congrats on patch in trunk
14:12<Zuu>PeterT: Thanks
14:14<Zuu>Go and test the filter sign list patch and I can probably soon suggest it too. ;-)
14:14<yarikos>planetmaker, where should i proceed when I got intel-only dmg with the bits in? forum? I could upload on
14:16<planetmaker>you'll not be the first with that on SF.
14:16<planetmaker>there's a openttdformac "project" or so
14:17<PeterT>Zuu: Ok
14:17<yarikos>ah, sorry, ottd is hosted elsewhere
14:17<PeterT>Zuu: what do I test?
14:17<PeterT>*what am I testing for?
14:18<Yexo>yarikos: compiling a mac binary has never been the problem, supporting it (and as such fixing the mac-specific bugs) is the problem
14:18<Yexo>that's the reason there are no mac binaries on
14:18-!-Splex [] has quit [Remote host closed the connection]
14:18<Zuu>See if it acts strange. Eg when you search for signs.
14:19<Zuu>mixing between using keyboard or mouse.
14:19<Yexo>of course you're free to upload it on the forums, but then it's at least a bit more clear that it's not an officially supported binary
14:19-!-Splex [] has joined #openttd
14:19<PeterT>oh good, #openttdcoop hasn't updated yet
14:19<PeterT>that means I can still use the binary you've provided
14:20<yarikos>then, while it still compiles (and appears working on 10.5) i can't download a binary like i did for years and have to dive in that all-gnu-like stuff?
14:21<yarikos>anyway, when i'll come up with a dmg, i'd like to share it with the world.
14:22<PeterT>Zuu: You said you changed the GUI to be like the Town window or somethign?
14:22<PeterT>What does tha tmean?
14:22<PeterT>*that mean
14:22<PeterT>I don't see a big difference
14:23<Zuu>In the sign list window?
14:25-!-KritiK [] has joined #openttd
14:26-!-Cybertinus [] has quit [Remote host closed the connection]
14:27-!-devilsadvocate [~devilsadv@] has quit [Ping timeout: 480 seconds]
14:31-!-Adambean [] has joined #openttd
14:35-!-fonsinchen [] has joined #openttd
14:37<PeterT>I can confidently suggest that Filter Sign List be introduced into trunk
14:37<PeterT>Zuu and I are testing it
14:39<planetmaker>PeterT: shouldn't the suggestion for inclusion be at the end of a successful test? ;-)
14:40<PeterT>planetmaker: So far, so good
14:49-!-Seki [] has joined #openttd
14:50<Seki>Is there a list of default building IDs somewhere, like there is for vehicles?
14:50<Yexo> for houses?
14:50<Yexo>or what kind of buildings?
14:51<Seki>I kept searching for "building" ids. Thanks :)
14:53-!-ecke [~ecke@] has joined #openttd
14:59-!-Leif_ [] has joined #openttd
14:59<yarikos>the forum doesn't support OpenIDs, does it?
15:00-!-Grelouk [~Grelouk@] has quit [Quit: Quitte]
15:00-!-Zuu [] has quit [Ping timeout: 480 seconds]
15:02-!-DanMacK [~DanMacK@] has quit [Quit: Bye for now!]
15:04-!-lobstah [~michielbi@] has joined #openttd
15:07<Alberth>Hmm, I seem to have switched from editing source to editing diffs. Not sure that is a step forward :p
15:08-!-Leif_ is now known as Zuu
15:08-!-lobstar [~michielbi@] has quit [Read error: Operation timed out]
15:08<Zuu>or makning diffs of diffs..
15:10<Eddi|zuHause>i don't think "meta-programming" was meant like this :p
15:11-!-KritiK [] has quit [Remote host closed the connection]
15:12-!-KritiK [] has joined #openttd
15:12-!-ptr [] has quit [Read error: Connection reset by peer]
15:13-!-ptr [] has joined #openttd
15:14<Alberth>Zuu: you get those when you put your patches under version control, still struggling to read those without getting confused.
15:23<Eddi|zuHause>diff-editing is sometimes useful to apply old patches
15:23<Eddi|zuHause>e.g. when they only conflict on some variable renaming
15:24-!-Progman [] has joined #openttd
15:27-!-Brianetta [] has joined #openttd
15:28-!-enr1x [~kiike@] has quit [Ping timeout: 480 seconds]
15:28<yarikos>ok, i've got the dmg (intel-only)
15:30-!-welshdragon [~markmac@] has quit [Quit: welshdragon]
15:31-!-devilsadvocate [~devilsadv@] has joined #openttd
15:33<OwenS>Mmmh.... Belgian chocolate
15:43-!-Alberth [] has left #openttd []
15:48-!-enr1x [~kiike@] has joined #openttd
15:48*TrueBrain concratz #openttd with its 20,000 download of 1.0.0
15:48<ddfreyne>OwenS: belgian chocolate is awesome :)
15:48<PeterT>TrueBrain: already? wow
15:49<planetmaker>that's quite awesome :-)
15:49<Ammler>19500 windows downloads :-)
15:50-!-lobstar [~michielbi@] has joined #openttd
15:50<planetmaker>TrueBrain: do you have stats on how many of those downloaded also Open[G|S]FX?
15:50<TrueBrain>planetmaker: all I can tell atm is that there were 60,000 downloads for BaNaNaS
15:50<planetmaker>hm... I'd be interested in those of 1.0.0, though.
15:50<planetmaker>The bananas download stats are accessible to me.
15:51<planetmaker>but not the installer.
15:51-!-Biolunar [] has joined #openttd
15:51<planetmaker>(stats of OpenGFX to be exact. not general bananas)
15:52-!-lobstah [~michielbi@] has quit [Read error: Operation timed out]
15:52<Ammler>hmm, dunno anymore, do you need mark opengfx for download
15:52<TrueBrain>we do not keep stats of the balancer yet, so that information can only come from the stats page, and I don't think it tracks opengfx .. you should ask Rubidium about that :)
15:52<Ammler>or would you need to unmark those for not downloading?
15:52<@Rubidium>it doesn't track the installer directory
15:54<Zephyris>Is there a way to get a time breakdown of a bananas file? That would be very interesting to see...
15:54<Zephyris>Meanings downloads of course...
15:54<@Rubidium>Zephyris: not for you; we got the data though
15:54<TrueBrain>0.8% IPv6
15:54*planetmaker is part of the big 99.2% horde
15:55<@Rubidium>Zephyris: I hope you meant some sort graph showing how many were downloaded at a specific date
15:55<@Rubidium>if you want to know the total counts, just go into the manager view and you can see it there (of your own stuff)
15:55<planetmaker>Rubidium: I guess somthing like n(t)
15:55<Eddi|zuHause>they should have turned off the internet to introduce ipv6, like they announced :p
15:55<planetmaker>would indeed be interesting :-)
15:56<TrueBrain>planetmaker: today alone, I count 6965 redirects for installer files
15:56<planetmaker>TrueBrain: thanks :-) Sounds like a bit :-)
15:56<TrueBrain>yesterday I count 10k
15:56<planetmaker>@calc 7000*3
15:56<@DorpsGek>planetmaker: 21000
15:57<planetmaker>ok... that was easy :-P
15:59<TrueBrain>2338 opengfx, 2304 opensfx :p
15:59<planetmaker>that's somewhat less than 7k
15:59<@Rubidium>openmsx misses
15:59<@Rubidium>also ~2300 I'd say
16:00<@Rubidium>@calc 3*2300
16:00<@DorpsGek>Rubidium: 6900
16:00<TrueBrain>I assumed you could do that math yourself :p
16:00<@Rubidium>i.e. pretty damn close
16:00<@Rubidium>@calc 6965-2338-2304
16:00<@DorpsGek>Rubidium: 2323
16:00<TrueBrain>rest are no-sound
16:00<@Rubidium>people still download that?
16:00<@Rubidium>that's like 1.0.0-beta era
16:02<TrueBrain>so people still download that :p
16:04<Ammler>that is only 10% downloading the open base sets?
16:04<planetmaker>hm... that's not a lot then.
16:05<TrueBrain>@calc (5227 + 8686) / (4079 + 6631)
16:05<@DorpsGek>TrueBrain: 1.29906629318
16:05<TrueBrain>@calc (4079 + 6631) / (5227 + 8686)
16:05<@DorpsGek>TrueBrain: 0.769783655574
16:05<TrueBrain>76% of the downloads so far is Windows, so sorry Ammler ;)
16:06<planetmaker>add the 1k downloads from bananas and the downloads from the devzone, but...
16:06<Zephyris>Rubidium: a graph of downloads would be amazing!
16:06<planetmaker>TrueBrain: what does that have to do with base set usage?
16:06<@Rubidium>Zephyris: and computationally very expensive
16:06<TrueBrain>planetmaker: I was not talking about that, don't know what you were talking about
16:06<TrueBrain>I was just commeting on that Ammler said that 19500 were Windows :p
16:07<Ammler>TrueBrain: nice :-)
16:07<Zephyris>Fair enough...
16:07<TrueBrain>@calc (821 + 1326) / (5227 + 8686)
16:07<@DorpsGek>TrueBrain: 0.154316107238
16:07<TrueBrain>16% Linux .. nice ..
16:07<@Rubidium>primarily because there are no indices on the stats table (and it's 8+ million entries long)
16:07<Ammler>with the fact that most linuxer uses distro repos...
16:08<TrueBrain>Rubidium: I should really write that new stats idea ;)
16:08<TrueBrain>Ammler: exactly
16:08<@Rubidium>TrueBrain: yeah, you should :)
16:08<TrueBrain>time time time
16:08*Ammler gives TrueBrain a min
16:08<TrueBrain>@calc 1841491 / 24 / 3600
16:08<@DorpsGek>TrueBrain: 21.3135532407
16:09<OwenS>Or just add indexes tro the stats table?
16:09<TrueBrain>21 hits per second .....
16:09<TrueBrain>(normal we run at 7 hits per second)
16:09<@Rubidium>OwenS: would make the table IIRC 8 times bigger
16:09<OwenS>Rubidium: Ouch
16:09<OwenS>Rubidium: What database & storage engine?
16:10<OwenS>My_ISAM, InnoDB...?
16:10<@Rubidium>don't know the storage engine, but I guess it's the default one
16:10<TrueBrain>doesn't really matter. How we store the data is just very inefficient
16:10<OwenS>I suppose a count of each "property" would be smarter? :p
16:10<OwenS>Though couldn't do correlations then
16:10<TrueBrain>that is what should be done
16:11<@Rubidium>OwenS: you mean only counting how often a particular file is downloaded?
16:12<@Rubidium>anyhow, the table just stores the file is and a date
16:12-!-enr1x [~kiike@] has quit [Ping timeout: 480 seconds]
16:12<OwenS>Rubidium: No, I meant something like the table is defined as (file_id integer, property_id integer, count integer), where property_id would be "Uses-Linux" or "Downloaded-With-Mozilla"
16:13<@Rubidium>OwenS: but that's useless for bananas stats
16:13<@Rubidium>you're not talking about TB's proposal, right?
16:13<OwenS>Rubidium: I hadn't had chance to read it when I said what I did ;p
16:13<@Rubidium>oh, it's using ISAM
16:14<@Rubidium>but bananas stats is just (file_id, date)
16:14<OwenS>InnoDB would probably be smaller. Or perhaps BDB
16:15<TrueBrain>wouldn't really matter. What we store is just very inefficient
16:15<@Rubidium>doubtful; it says a record is 13 bytes, 8.5 million records -> 105 MiB
16:15<OwenS>I was refering to InnoDB or BDB's indexes
16:15<TrueBrain>if you store 1 record for every download, there is just no way to store it efficiently :p
16:16<@Rubidium>download stats just store file, "hour", count and has 0.25 million records
16:17<@Rubidium>for 1.2 million downloads
16:17-!-nfc [] has quit [Read error: Connection reset by peer]
16:17-!-nfc [] has joined #openttd
16:17<Seki>Random question: Does delivering goods to a town actually help it grow?
16:18<planetmaker>doesn't. unless it's one of 5 serviced stations.
16:18<Seki>Hmm, should the Wiki not say it does, then?
16:18<Seki>Thanks though :)
16:18-!-devilsadvocate [~devilsadv@] has quit [Quit: Leaving]
16:19<Eddi|zuHause>Seki: it's a very sticky myth, those are difficult to keep out of wikis
16:19<Seki>Eddi: That makes sense, then. Thanks for the clarification.
16:19<Eddi|zuHause>Seki: please edit it out of the wiki page you read :)
16:20<Eddi|zuHause>or better: specifically say the opposite :)
16:21<Seki>That was the plan - before I edit it: Food?
16:21<Seki>Does it speed town growth, other than as a requirement for desert/snow towns to grow
16:22-!-Zephyris [~Zephyris@] has quit [Read error: No route to host]
16:22<Seki>As updating on wiki: Delivery of Goods or Food has no effect on the speed of town growth.
16:22<Eddi|zuHause>Seki: the only thing that counts (other than the requirements) is serviced stations. which cargo is transported is irrelevant
16:23-!-Zephyris [~Zephyris@] has joined #openttd
16:24-!-Rhamphoryncus [] has joined #openttd
16:26-!-Muxy [] has joined #openttd
16:42-!-Zephyris [~Zephyris@] has quit [Quit: Bye]
16:42-!-Zephyris [~Zephyris@] has joined #openttd
16:43-!-Seki [] has left #openttd [Leaving]
16:43-!-Seki [] has joined #openttd
17:00-!-Nite_Owl [] has joined #openttd
17:00<Nite_Owl>Hello all
17:06-!-Terkhen [] has quit [Ping timeout: 480 seconds]
17:07-!-Terkhen [] has joined #openttd
17:09-!-rubenvincenten [] has left #openttd []
17:12*andythenorth needs an offset editor
17:13-!-snack2 [] has quit [Quit: ( :: NoNameScript 4.22 :: )]
17:13<Zuu>hm, the tool that glx or some other dev made do not offer that?
17:13<blathijs>planetmaker: lintian complains about the .hgtags file in the source tarball
17:13<blathijs>planetmaker: I guess that shouldn't be in there?
17:14<planetmaker>well... it needn't, yes
17:14<planetmaker>I simply defined "source" as "whatever is tracked"
17:15<planetmaker>and only started to add exceptions :-)
17:15<blathijs>It's sort of a metadata file that IMHO doesn't even belong inside a repository anyway, but well :-p
17:15<blathijs>planetmaker: Would it be easy to remove it? Now I have a lintian warning :-)
17:15<@Rubidium>blathijs: it happens with all distributed VCSes I know
17:16<planetmaker>blathijs: in the tar ball: yes
17:16<planetmaker>but it must be part of the repo
17:17<blathijs>planetmaker: Yeah, that's fine. I won't ask you to fix (what I consider) deficiences in hg :-p
17:17<blathijs>Rubidium: Uh, git just stores tags in the .git directory
17:17<blathijs>Rubidium: This is about tags, not ignore
17:17<planetmaker>blathijs: that's no deficiency. How else would you handle tags in a _distributed_ VCS?
17:17<@Rubidium>blathijs: but not .gitignore
17:17<@Rubidium>which is *also* metadata
17:18<blathijs>planetmaker: Like git does?
17:18<planetmaker>how does it do it?
17:18<planetmaker>How do others know about tags?
17:18<blathijs>planetmaker: Just store them in the .git directory and push and pull them as part of the git protocol
17:18-!-hron841 [] has joined #openttd
17:18-!-hron84 [] has quit [Read error: Connection reset by peer]
17:18<blathijs>Rubidium: I think .gitignore is less ugly, but that's probably only because I'm used to it :-p
17:19<planetmaker>blathijs: yes... but what's the difference to a .hgtags file now? I see no difference really.
17:19<blathijs>planetmaker: That the .hgtags file is now part of the _content_ of the repository
17:20<blathijs>If I really wanted to put a file called '.hgtags' in my repository, I can't, because that name is special
17:20<blathijs>And if I do an export of a repository, I get that file as well
17:21<blathijs>But these reasons really mean that .gitignore is ugly as well :-)
17:21<blathijs>But I guess that having infrastructure to push and pull tags (like git has) is defendable, but pushing and pulling an ignore file is folly :-p
17:22-!-DDR [~chatzilla@] has joined #openttd
17:23-!-tdev [] has quit [Quit: Leaving]
17:24-!-hron841 [] has quit [Quit: Leaving.]
17:26-!-Grelouk [] has joined #openttd
17:26-!-Kurimus [] has quit []
17:28<planetmaker>yeah...maybe :-)
17:30-!-Nite_Owl [] has quit [Quit: Read You Soon]
17:30-!-Kurimus [] has joined #openttd
17:31<CIA-6>OpenTTD: yexo * r19547 /trunk/src/newgrf.cpp: -Fix [FS#3725]: properties set before prop 08 should be ignored, not trigger the newgrf to be disabled
17:32<Eddi|zuHause>did you mean "action 8"?
17:32-!-devilsadvocate [~devilsadv@] has joined #openttd
17:32<@Rubidium>that would be too obvious
17:34<Yexo>Eddi|zuHause: no, property 08
17:34<Yexo>maybe I should've mentioned it it's only for houses, industries and industry tiles
17:35<Eddi|zuHause>ah, so it's something entirely different than i thought
17:37-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
17:41<Yexo>reading the FS task should make it more clear
17:42<andythenorth>good night
17:42-!-andythenorth [] has left #openttd []
17:47<blathijs>Rubidium: I guess the "attempt to free a non-heap object" warnings were already known?
17:47<@Rubidium>blathijs: did you look at the code causing it?
17:47<blathijs>IIRC you reported that as a gcc bug, or didn't you?
17:48<blathijs>No, I just saw the warnings fly by
17:48<@Rubidium>yes I did
17:48<blathijs>Then I did look at the code, a while ago :-)
17:48<@Rubidium>and it's bogus as described in readme.txt and the code
17:48<@Rubidium>it only "happens" when compiling without assertions
17:49<@Rubidium>as the assertion for some reason makes GCC not notice it
17:49-!-Grelouk [] has quit [Read error: Connection reset by peer]
17:54<@Rubidium>"kweet niet hoe het kan, maar profiteer er van" :)
18:08-!-Progman [] has quit [Remote host closed the connection]
18:09-!-zodttd [] has quit [Remote host closed the connection]
18:11-!-Chruker [] has quit []
18:22<Zuu>Hmm, the Land Area info window do not refresh when you change language.
18:22<Zuu>Serious bug! :-p
18:25<Terkhen>good night
18:25-!-Terkhen [] has quit [Quit: ...]
18:28<Yexo>Zuu: it won't update either if the tile you clicked is changed
18:29-!-welshdragon [~markmac@] has joined #openttd
18:29<Zuu>Ok, noticed that it does change the title, but not the contents. Guess the window simply don't store the tile.
18:30<Yexo>the title is just a StringID, like most strings used in windows
18:31<Yexo>the contents of that window are an exception, they're stored as C-strings
18:35<@Rubidium>there are simply too many corner cases with the window that updating it each tick is worth it
18:36<@Rubidium>for one we'd need to hook into *all* and *every* map accessor that changes the map
18:36<@Rubidium>so we can tell the window to update when needed
18:36<@Rubidium>which means lots of trouble
18:37<@Rubidium>also storing the non-resolved strings isn't an option because then it'll crash when removing some stuff (towns, stations, companies, ...)
18:38-!-DDR [~chatzilla@] has joined #openttd
18:42-!-ragzid [~ragzid@] has joined #openttd
18:42<Zuu>What does the "mark" button at webtranslator does? Does it mark the translation validated?
18:43<@Rubidium>no, it marks it so it gets into the "strings needing validation" group
18:43<Zuu>Strings that need validation is that strings where english.txt has changed or is it just that nobody has looked at someone else translation and validated it?
18:43<@Rubidium>those are strings that changed in English or strings that were marked by other translators
18:45<Zuu>And to validate a string you (after having checked that the translation is ok) click on the save button?
18:45<Zuu>Sorry for asking, but can't find this documented at the faq/wiki
18:45-!-Brianetta [] has quit [Quit: Tschüß]
18:47-!-Adambean [] has quit [Quit: Gone fishing]
18:50-!-R-Blade [~W@] has joined #openttd
18:50-!-R-Blade [~W@] has quit []
18:54-!-einKarl [] has quit [Remote host closed the connection]
19:05-!-Chrill [] has joined #openttd
19:06-!-fonsinchen [] has quit [Ping timeout: 480 seconds]
19:22-!-Neon [] has quit [Quit: Something strange must have happened...]
19:28-!-ragzid is now known as ragzid|ZzZz
19:29-!-KritiK [] has quit [Quit: Leaving]
19:37-!-Zuu [] has quit [Quit: Leaving]
19:42-!-valhallasw [] has quit [Ping timeout: 480 seconds]
19:48-!-Tennel [] has quit [Quit: WeeChat]
19:59-!-Eddi|zuHause [] has quit []
19:59-!-Eddi|zuHause [] has joined #openttd
20:03-!-ragzid|ZzZz [~ragzid@] has quit [Quit: leaving]
20:07-!-davis [] has joined #openttd
20:10-!-Chrill [] has quit []
20:13-!-OwenS [] has quit [Quit: Leaving.]
20:14-!-heffer [] has quit [Quit: heffer]
20:16-!-KenjiE20 [~KenjiE20@] has quit [Quit: おやすみ]
20:40-!-davis [] has quit [Read error: Connection reset by peer]
20:48-!-Nite_Owl [] has joined #openttd
20:48<Nite_Owl>Hello all
20:50-!-Nite_Owl [] has quit []
21:00-!-Coco-Banana-Man [] has quit [Quit: Regel Nr. 1: Jeder hört auf mein Kommando! - Regel Nr. 2: Jeder bleibt auf dem Weg! - Regel Nr. 3: ... ... Der, der bläht, als hinterster geht!]
21:05-!-fjb is now known as Guest1107
21:05-!-fjb [] has joined #openttd
21:12-!-Guest1107 [] has quit [Ping timeout: 480 seconds]
21:12-!-aber [] has quit [Ping timeout: 480 seconds]
21:14-!-aber [] has joined #openttd
21:21-!-aber [] has quit [Quit: Leaving.]
21:37-!-DDR_ [~chatzilla@] has joined #openttd
21:40-!-ptr [] has quit [Quit: Zzzzzz]
21:42-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
21:43-!-DDR_ is now known as DDR
21:52-!-Eddi|zuHause [] has quit [Remote host closed the connection]
21:54-!-Eddi|zuHause [] has joined #openttd
21:58-!-Biolunar_ [] has joined #openttd
22:04-!-Lapsus [] has joined #openttd
22:04<Lapsus>Hello! :3
22:06-!-Biolunar [] has quit [Ping timeout: 480 seconds]
22:06<Lapsus>I recall there being a php server configurator for openttd floating around, but I can't find it. Anyone willing to help me look? :o
22:08<PeterT>Lapsus: I know what you're talking about
22:08<Lapsus>Hooray, I didn't hallucinate it! :D
22:09<Lapsus>Awesome :3
22:09<Lapsus>Thanks you <3
22:10<PeterT>but the links don't work
22:10<Lapsus>haha, just noticed
22:12-!-a1270 [] has quit [Quit: a1270]
22:14-!-a1270 [] has joined #openttd
22:27-!-glx [glx@2a01:e35:2f59:c7c0:7978:eeba:93a2:315] has quit [Quit: bye]
22:35-!-lobstar [~michielbi@] has quit [Read error: Operation timed out]
22:39-!-lobstar [~michielbi@] has joined #openttd
22:51-!-Lapsus_ [] has joined #openttd
22:52-!-Lapsus is now known as Guest1113
22:52-!-Lapsus_ is now known as lapsus
22:53-!-lapsus is now known as Lapsus
22:58-!-Guest1113 [] has quit [Read error: Operation timed out]
23:00-!-DanMacK [~here@] has joined #openttd
23:06-!-llugo [] has joined #openttd
23:14-!-lugo [] has quit [Ping timeout: 480 seconds]
23:22-!-ajmiles2 [] has quit [Read error: Connection reset by peer]
23:29<Lapsus>Hooray, an internet storm.
23:51-!-Wizzleby [] has quit [Remote host closed the connection]
23:55-!-welshdragon [~markmac@] has quit [Quit: welshdragon]
23:59-!-Dred_furst [] has quit [Ping timeout: 480 seconds]
---Logclosed Sat Apr 03 00:00:28 2010