IRC logs for #openttd on OFTC at 2010-04-02
⏴ go to previous day
00:05:54 *** lobstar has joined #openttd
00:09:08 <Ammler> but I am not sure, if there is a open ticket about that
00:09:36 <PeterT> Lapsus: What is the crash?
00:09:37 <Ammler> I know, Autopilot works fine with 1.0.0, we just tested today
00:11:14 <Lapsus> It's actually working perfectly on another server being run from the same machine, and I'm guessing that's the cause of the issues. :P
00:12:45 <Ammler> sometimes, we run around 3 servers on the same machine
00:12:49 <Lapsus> PeterT: pastebinning it
00:12:57 <PeterT> I saw the previous one
00:13:06 <PeterT> I don't know what that's about
00:13:07 *** Coco-Banana-Man has quit IRC
00:13:14 <PeterT> you trying to use sameports or something?
00:14:03 <Lapsus> Nah, that's the issue I was having earlier :P
00:14:51 <Ammler> then paste your new issue
00:16:12 <PeterT> what channel/network is this on?
00:16:25 <Lapsus> It's on irc.toribash.com #openttd
00:16:25 <PeterT> (not that it's relevant, just wondering)
00:17:00 <Lapsus> Trying to get a server up for the community, as it was a hit when I was running 0.7.5, but most fo the community is too dense to get opengfx working on their own
00:17:17 <Ammler> Lapsus: you should kill autopilot.tcl
00:18:38 <Lapsus> apparently there were four servers running with the same files, I'd killed two of them
00:19:10 <Ammler> if you kill autopilot, it will also kill openttd child
00:20:06 <Lapsus> Okay, everything appears to be running now, at least
00:23:11 <Ammler> how is that relevant to opengfx?
00:23:53 <Lapsus> the installer for 1.0.0 includes the option to install opengfx, thus making getting people up and running a hundred times easier
00:24:46 <Ammler> client doesn't care what base set you run on the server
00:25:39 <Lapsus> No, but the number of people I have whining at me about the game not working in a Let's Play thread drops sharply when I can point them at an easy-to-use installer that gets everything they need.
00:26:06 <Lapsus> The server issues are only relevant to my own stupidity
00:30:08 *** SirSquid1ess has joined #openttd
00:36:41 *** SirSquid1ess is now known as SirSquidness
00:50:39 <DarkED> hi all, i am having a strange issue. i just installed openttd 1.0.0 in linux. i then extracted opengfx 0.2.3 and opensfx 0.2.3 into my ~/.openttd directory, but openttd says it failed to find a graphics set
00:50:55 <DarkED> is there something i'm missing?
00:51:40 <PeterT> opengfx goes in ~/.openttd/data
00:52:19 <DarkED> yep, works as expected now.
00:52:32 <DarkED> the folder wasn't there by default, thus i didnt think of it. thanks!
00:52:47 <PeterT> many folders aren't there if they aren't needed
00:52:56 <PeterT> such as ~/.opentd/scripts/
00:53:05 <PeterT> only necesarry for...well...scripts ;-)
01:12:49 <Starn> woo i have feeling my clan is going to ban me lol just put out my opinion on political correctness >.<
01:37:44 <PeterT> can we please please please please PLEASE have mode +M ?
01:39:05 <PeterT> no, +M only allows people who are registered and identified
01:39:22 <Starn> ah! aww dang i wanted to mute my self ;)
01:39:49 <Starn> i am registered to nickserv ^^
01:43:53 *** rhaeder has joined #openttd
01:44:48 <Starn> hey do you people know the american laws and internet laws for service providers such as ATT?
01:45:26 *** Dred_furst has joined #openttd
01:45:43 <Starn> like on if they are truely allowed to kick people off the internet with out warning telling them they have illegal software on their computer and will stay shutoff from internet until they remove it?
01:55:43 <Starn> mmm i like +o on my name ^^ <3 my channel on another server lol its empty.. my clan is being d bags and not joining than again most of them don't even know what IRC is lol
01:56:34 <Starn> allows me to also test my AI and channel bot
01:56:55 <Starn> i've spent over an year codding her
01:57:05 <Starn> gamesurge.. she is not oporational yet
01:58:12 <Starn> she uses AIML for language abilitys german english and spanish and the english one is one i've worked on i am having trouble making it work with that.. it can connect and do simple irc task nothing more.
01:58:33 <Starn> i know its not online or up..
01:58:54 <Starn> last time i compiled it did not talk so i have been trying to work that out.
01:59:20 <Starn> it runs better on linux also despite its cross platform
01:59:34 <Starn> uses python and like i said aiml
02:00:12 *** Biolunar_ has joined #openttd
02:00:16 <Starn> would love to learn C++ and convert her over to C++ for it would provide me with more options ya know.
02:01:20 <Starn> have an slightly older fewer IRC commands on google codes if you wanna look at the basic connection method and maybe even see how i am trying to implant the brian :)
02:01:47 <PeterT> what is the project name?
02:02:11 <Starn> one sec leme find it in my bookmarks something with my real name and ai or something lol
02:03:48 <Starn> hmm 2007 i was young :P so expect crappy code
02:05:38 <Starn> that is freakin sweet mate
02:06:10 <PeterT> Unfortunately the main developer left for the navy
02:06:13 <Starn> probably way more advance than my crap
02:06:22 <PeterT> and he gave me commit access
02:06:36 <PeterT> all I've done with that wrapper is a stupid little !cycle patch
02:06:39 <Starn> ah i see. that is unfortunate that he did leave.
02:07:23 <Starn> i miss working with the torque engine simple code i liked it wish creating bots was as easy as making a game with torque lol
02:08:24 <Starn> i had a pretty good role in blocklands mod TBM and worked out a patch to have a working weather system and few other patches to help with speed and proformance
02:09:14 <Starn> hey PeterT wanna help me be lazy?
02:10:06 <Starn> suggest a pre made IRC bot simple to use and setup as a fast deploy method to controle my channel for my project i have a feeling will never be done.
02:10:20 <Starn> i've grown to lazy and undedicated
02:10:26 *** WizzleBLincoln has quit IRC
02:10:41 *** Wizzleby has joined #openttd
02:11:06 <PeterT> I suggest an IR....I'm tired
02:11:31 <Starn> ir? lol :P you stink for being tired.. here have some vodka and sugar
02:11:46 <Starn> btw that sounds extremely gross
02:16:43 <Rhamphoryncus> Starn: ISP contracts often have clauses about misuse, such as sending spam email. If they detect crap like that they may very well stop their service with you
02:17:25 <Starn> thats what i was thinking only thing stated in their contract that would be shut off with out notifying is spam email.
02:17:48 <Starn> which in that case they was attacked by virus. which i laugh at them for trusting mcaffee lol
02:18:36 <Rhamphoryncus> *shrug* there's probably a more general clause in there somewhere
02:18:54 <Rhamphoryncus> And regardless, any reasonable ISP will disconnect customers for that
02:19:29 <Rhamphoryncus> An excessively unreasonable ISP would themselves be disconnected if they didn't. They'd become a haven for abusive behaviour
02:22:06 <Starn> all i know is my uncles internet was shutoff and they told him that he has illegal software lol but he only has defualt windows software and ubuntu defualt software used for open office and browsing the web. and other computer is laptop with microsoft money and other related things used for restruant
02:23:14 <Rhamphoryncus> Probably has malware. Most of it goes undetected
02:25:01 <Starn> yea. i am assuming this as well
02:30:17 <Eddi|zuHause> <PeterT> no, +M only allows people who are registered and identified <-- i strongly reject this idea
02:32:21 <Eddi|zuHause> a) i'm not registered and i don't intend to do so
02:32:43 <Eddi|zuHause> b) not every person should have to register for a simple question
02:34:07 *** DanMacK has joined #openttd
02:46:14 <PeterT> Eddi|zuHause: why don't you register?
02:49:40 * Starn ponders on why Eddi|zuHause does not register. than a tiny tiny tiny tiny light bulb pops up
02:50:24 <Eddi|zuHause> that may be true, but possibly only a correlation, not a causality :p
02:50:45 * Starn is stunned for he did not expect to be right
04:10:35 *** deghosty has joined #openttd
04:14:38 *** De_Ghosty has joined #openttd
04:16:37 *** mikegrb has joined #openttd
04:32:22 *** De_Ghosty has joined #openttd
04:32:22 *** lobstar has joined #openttd
04:32:22 *** FauxFaux has joined #openttd
04:54:40 *** welshdragon has joined #openttd
05:28:36 <welshdragon> hmm, where can i find out about the changes in 1.0.0?
05:28:48 <welshdragon> i know there are the new base sets
06:21:24 *** Kurimus has joined #openttd
06:29:45 *** Cybertinus has joined #openttd
07:46:36 *** ADMINtur has joined #openttd
08:19:49 *** Alberth has joined #openttd
08:28:26 *** Biolunar_ is now known as Biolunar
08:34:40 *** Progman has joined #openttd
08:49:42 *** devilsadvocate has quit IRC
08:52:58 *** Terkhen has joined #openttd
09:15:07 *** devilsadvocate has joined #openttd
09:24:26 <andythenorth> does it matter if vehicle bounding boxes are accurately sized (or not)?
09:31:33 <Alberth> don't know exactly, but I guess: too small -> clipping problems. too big -> possibly draw order problems
09:32:07 <Alberth> but this is an extremely difficult issue, see FS#119
09:34:53 <andythenorth> Alberth: thanks. Hmmm....how to template the bounding box for ships....I'll go figure that out.
09:37:00 <planetmaker> andythenorth: if it's a bit too big that's not really a big deal
09:37:26 <andythenorth> and if it's a very lot too big? :P
09:37:54 <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
09:38:28 <planetmaker> andythenorth: well... try. My guess is that it's most probably not too problematic. But it depends upon the definition of "too big"?
09:39:44 <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) :)
09:39:54 <andythenorth> either way....boring :P
09:40:48 <planetmaker> why do you need to re-calculate xy offsets?
09:41:07 <andythenorth> if the bounding box size changes, the xy offs will be wrong.....
09:41:13 <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.
09:41:23 <planetmaker> don't change either, andythenorth. Use the same :-)
09:41:54 <andythenorth> xy offs are calculated according to center of bounding box (according to wiki spec)
09:42:12 <planetmaker> what's the problem then?
09:42:20 <planetmaker> same bounding box, same offsets
09:42:35 <planetmaker> ship will always be aligned wrt its centre
09:43:02 <andythenorth> problem is the 15 or so ships that already have bounding boxes (different) and offsets
09:43:04 <planetmaker> IF the ship sprites are centred in their templates that is.
09:43:27 <planetmaker> that's bad luck then. Happy aligning ;-)
09:45:02 * andythenorth ponders centering all sprites in the pcx templates
09:45:10 * andythenorth wants an apprentic
09:45:29 <planetmaker> that's what is done in OpenGFX and 2cctrainset at least :-)
09:49:03 <planetmaker> hey Zephyris, your 32bpp version of it looks awesome by what I've seen in the forums
09:51:39 <Zephyris> Thanks! My little push to a 32bpp future...
09:57:44 <planetmaker> yeah... it's a nice addition. I'm not too sure about the current implementation of the zoom-levels patch, though...
09:57:54 <blathijs> planetmaker: Makefile.local(.sample) and Makefile.def in opengfx have different opinions about UNIX2DOS's default value
09:57:58 <blathijs> Makefile.local:# UNIX2DOS = $(shell [ `which unix2dos` ] && echo "unix2dos" || echo "cat")
09:58:01 <blathijs> scripts/Makefile.def:UNIX2DOS ?= $(shell [ `which unix2dos 2>/dev/null` ] && echo "unix2dos" || echo "")
09:58:36 <planetmaker> blathijs: Makefile.def is used.
09:58:50 <planetmaker> Obviously I forgot to update the Makefile.local.sample
09:59:06 <blathijs> planetmaker: Yeah, it's not an issue, just a small incosnsitency :-)
09:59:07 <planetmaker> do you need to customize that?
09:59:20 <planetmaker> ah, ok :-) Yeah, thanks for reporting :-)
09:59: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
10:01:05 <blathijs> But that's why I notifced
10:01:44 <planetmaker> Do you still need a patch wrt unix2dos?
10:04:12 <blathijs> There used to be a bashism in the use of "type", but you changed to use which, which should work better
10:04:20 <planetmaker> please keep telling me, if / whether you need changes. Better fixing it at the source than each distro separately.
10:04:52 <blathijs> planetmaker: Of course :-)
10:06:51 *** JVassie has joined #openttd
10:07:40 <blathijs> planetmaker: What's this "Debian support" I see in the changelog?
10:08:11 <planetmaker> that's Debian using nforenum instead of renum as the binary name for... nforenum
10:08:28 <blathijs> I heard about that already
10:08:45 <planetmaker> makes sense in some respect, but not much in other ;-)
10:22:25 <blathijs> planetmaker: I guess upstream should just use "nforenum" as well
10:22:48 <blathijs> I mean, the project is even called "nforenum", just not the binary
10:23:58 <planetmaker> blathijs: yes. But there's a difference between 'should' and 'does'.
10:25:25 <blathijs> But well, it works now :-)
10:25:53 <blathijs> Seems I could build opengfx 0.2.3 without problems, btw (and without local patches :-D)
10:26:13 <blathijs> Haven't tried in a clean chroot yet, because I'm on a crappy connection
10:28:44 <planetmaker> anyway that's good news :-)
10:28:58 <planetmaker> (I don't mean your connection, though)
10:29:39 * andythenorth seriously regrets not centering these ships earlier
10:29:52 <andythenorth> multi-layer photoshop files are not fun to center
10:36:04 <planetmaker> andythenorth: maybe you could create a pcx template like pikka did with the trains
10:36:12 <planetmaker> (or a few for different sizes)
10:36:27 <andythenorth> I was wondering the same thing
10:36:34 <planetmaker> he outlined the acceptable sizes in the templates.
10:37:00 <andythenorth> I don't think it matters for ships....they don't have to line up with each other like trains / aRVs
10:37:11 <andythenorth> one for trucks is going to be needed though
10:37:38 <planetmaker> I guess the train ones could be used - at least the pcx side
10:37:47 <planetmaker> maybe offsets would need changing
10:38:03 <andythenorth> project for another day
10:43:04 <blathijs> Hmm, make mrproper in opensfx throws away the md5 sums...
10:43:42 <blathijs> Hm, seems opengfx does that as well
10:44:33 <blathijs> planetmaker: Any comments on that?
10:45:12 <planetmaker> well. That's by design
10:45:30 <planetmaker> mrproper should clean everything which is not part of the repository
10:45:40 <planetmaker> such if I'm in my hg repo, it needs to clean that.
10:45:52 <planetmaker> In a source tar ball... well... there it's part of the repo...
10:46:42 <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
10:46:56 <blathijs> I'd expect make mrproper to clean up into a pristine tarball :-)
10:46:57 <planetmaker> or rather on how to do so in a decent way
10:47:15 <planetmaker> yes, understandable with a tar ball :-)
10:47:39 <blathijs> I think "make clean" is usually supposed to clean up what "make" leaves behind, and "make mrproper" should clean up what ./configure creates
10:47:53 <blathijs> But there isn't really a tarball, of course
10:47:55 <planetmaker> well Then clean should clean all.
10:48:01 <blathijs> What are the other files mrproper cleans up?
10:48:03 <planetmaker> as we don't use ./(configure
10:48:34 <planetmaker> mrproper cleans also the dirs created from make bundle*
10:50:25 <planetmaker> clean only cleans everything not created by bundle*
10:51:49 <planetmaker> it's defined in scripts/Makefile.common
10:56:51 <planetmaker> hm, I should possibly consider to provide a ./configure script, too. That might speed up later makefile runs possibly considerably
10:57:29 <blathijs> Hmm, but make install uses bundle* as well, right?
10:57:43 <blathijs> so clean doesn't clean up what make install does?
11:00:10 <planetmaker> not everything. That's true
11:03:08 *** KenjiE20 has joined #openttd
11:04:20 <CIA-6> OpenTTD: yexo * r19538 /trunk/src/industry_gui.cpp: -Fix: sorting industries by production was broken for newgrf industries
11:05:55 *** zodttd2 is now known as zodttd
11:11:01 <blathijs> planetmaker: So perhaps add a third cleaning target, then?
11:11:52 *** Coco-Banana-Man has joined #openttd
11:14:38 <blathijs> planetmaker: Perhaps "distclean" to restore the tarball state?
11:15:31 <planetmaker> I could do that, yes. Is distclean the proper name for that?
11:17:52 <planetmaker> hm... well. why not :-)
11:19:05 <blathijs> planetmaker: I'll have a patch in a minute, testing it now
11:20:18 <Alberth> but perhaps you want automake targets
11:22:06 <planetmaker> Alberth: I don't use automake. The standard make manual you gave is what I consider my guideline :-)
11:22:42 <planetmaker> though... that gives the same targets :-)
11:23:26 <blathijs> It doesn't define any "repo-clean", rally
11:23:36 <oskari89> Hmm, has anyone done articulated version of long vehicles? For example, the Dolphin bus? :P
11:24:25 <blathijs> planetmaker: What is the $(DIR_BASE)* supposed to clean up? It throws away the MD5 file as well :-)
11:24:26 <planetmaker> blathijs: in principle the mrproper cleans everything which is not repo
11:24:55 <planetmaker> blathijs: yes.... it cleans a lot of generated files and dirs
11:25:03 <planetmaker> they all start with opengfx-<version>
11:26:55 <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
11:27:33 <blathijs> Alberth: Even though there isn't really a ./configure, I think ./configure never generates anything which is in the tarball
11:28:15 <blathijs> So distclean shouldn't delete the md5 sums
11:28:22 <Alberth> usually not, indeed afaik
11:28:30 <blathijs> (which are in the tarball, an not the repo)
11:28:41 <blathijs> so we were looking for a name for "repo-clean", that also deletes the sums
11:29:26 <blathijs> planetmaker: but that removes the $(DIR_BASE)*, so that might need to be replaced by a exhaustive list instead?
11:29:44 <planetmaker> blathijs: $(DIR_BASE)* is usually fine
11:30:02 <planetmaker> opengfx-<version>* is always an output of the make process
11:30:35 <blathijs> planetmaker: But that includses opengfx-0.2.3.md5
11:31:32 <Alberth> why not make the md5 sums depend on the file they compute, so they are kept in sync automagically?
11:32:22 <Alberth> ie, why would you want to remove them explicitly? hg up -C or so would take care for such things, wouldn't it?
11:32:59 <planetmaker> Alberth: very bad idea that dependency
11:33:20 <planetmaker> it would mean it's not possible to check for integrity when building from a tar ball.
11:33:34 <planetmaker> Removing that is one of two reasons for 0.2.3 to appear
11:36:27 * Ammler wonders, what is the point of building it self, if you need to have the same md5sum...
11:37:57 <Alberth> only integrity checking of the data files, probably.
11:38:14 * Alberth wonders whether 'tar' doesn't do that as well.
11:39:34 <Alberth> integrity checking of the files it creates
11:40:32 <Alberth> ie, it should be able to detect a bad tape block, woudn't it?
11:40:51 <planetmaker> Alberth: sure. But that doesn't check whether you built the same md5sums grfs from the source as I did
11:41:04 <planetmaker> That's the whole point of the supplied *.md5 file
11:41:38 <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
11:41:42 <Ammler> for example the official suse maintainer uses the binary zips
11:42:19 <Alberth> planetmaker: shouldn't the sums be stored with the sources then?
11:42:22 <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)
11:42:33 <planetmaker> Alberth: they are - for source tar balls
11:42:44 <planetmaker> but there's no point to make it a source file in the repo
11:43:52 <Alberth> you store the md5 sums in release tags, I hope
11:44:08 <planetmaker> actually little as it'd change with every nearly every commit and would need updating then and is not needed.
11:44:21 <Ammler> Alberth: in hg, tags are real tags :-)
11:45:01 <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
11:45:04 <Alberth> so you can reproduce the source tar ball exactly, and verify that you can build the exactly same grf
11:46:03 <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
11:46:03 <Ammler> Alberth: doesn't need to be true, if source matches, doesn't mean the final grf will have matching md5sum
11:46:04 *** DanMacK has joined #openttd
11:46:52 <Ammler> for example, grfcodec is broken with suse factory and there it does produce different grfs
11:46:54 <Alberth> Ammler: we were discussing md5 sums of grf files, or am I mistaken?
11:47:40 <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"
11:48:16 <planetmaker> Alberth: Ammler you're talking of different things ;-)
11:48:22 <planetmaker> And mean the same :-P
11:48:26 *** Adambean has joined #openttd
11:48:44 <Ammler> you mean, if you build the grf from exact the same source, you should get the same grf, which is wrong.
11:48:54 <planetmaker> Ammler: no he doesn't
11:49:12 <planetmaker> he says that we should note down the md5sums which we want to be created from the source.
11:49:27 <planetmaker> for exactly the reason you state
11:49:57 <Ammler> you need to build the grf to get md5sum
11:50:24 <Alberth> planetmaker: I'd probably even consider them part of the repo, but that is policy
11:50:31 <OwenS> Ammler: You build the GRF and generate the MD5SUM. Users can check against it to ascertain if their grfcodec is working
11:51:01 <planetmaker> OwenS: that's what we do. For source releases.
11:51:58 <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?
11:52:53 <Alberth> or even, how are you going to reproduce a md5 sum for a old release, after you upgraded to a newer grfcodec?
11:53:33 <Ammler> I think, you can test that with release souces
11:53:54 <Yexo> the md5sum could even be different if one users uses -c (crop extra transparant blue) as option for grfcodec and another does not
11:54:05 <Yexo> although both grfs will be valid they'll still be different
11:54:17 <planetmaker> Yexo: those options are usually set via the Makefile...
11:54:30 <Ammler> the md5sums are also on the nightly available
11:54:55 <Yexo> planetmaker: so if a user overrides some options in makefile.local their build-chain is suddenly 'invalid'?
11:55:25 <planetmaker> If I override build options in OpenTTD I also end up with a different binary
11:55:38 <planetmaker> I see no problem with that
11:55:44 <Priski> why does Openttd randomize its listening port?
11:55:52 <Ammler> the grf might work, but is invalied
11:56:06 <planetmaker> not invalid. Just not a release version
11:56:09 <Ammler> from point of openttd version check
11:56:11 <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
11:56:28 <Yexo> although for grfs you might have a point
11:56:31 <Ammler> Yexo: openttd does that
11:56:49 <planetmaker> Yexo: So: how else, than by a md5sum do you check for whether you built a release version? It's the only way.
11:57:03 <planetmaker> If you do it differently you end up with a grf. But not with the one we released. Quite natural
11:57:10 <Yexo> you're right, I forgot that for newgrfs the md5sum is actually part of their 'version'
11:57:10 <Ammler> but it also helpps us to test builds, for example, I know now, that suse factory has broken grfcodec
12:01:24 <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
12:02:07 *** Luukland has joined #openttd
12:02:59 <Ammler> well, maybe we could indeed commit the md5sums of releaes
12:03:59 <Alberth> planetmaker: yep, the problem is only re-constructing a release literally from scratch.
12:04:10 *** DanMacK has joined #openttd
12:04:26 <Alberth> (perhaps copy the sum from that file while building a release)
12:04:27 <planetmaker> Alberth: I think the solution is to add the md5sums to the readme. That is even half integrated in the makefiles
12:04:50 <planetmaker> then there's no real check, but you have the expected md5sum for every build.
12:05:04 <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?
12:05:24 <PeterT> It's likely just your server
12:05:40 <Alberth> oh, you don't have a special script for building a release? yeah, then the md5sum may not be present.
12:07:40 *** rubenvincenten has joined #openttd
12:07:43 *** Chruker has joined #openttd
12:09:08 <planetmaker> Alberth: not really a special script. The same as for nightlies. Just the tag'ed version
12:10:59 <rubenvincenten> Hey, I have a quick question. I'm running OS X and would like to know which release I have to choose?
12:11:37 <planetmaker> rubenvincenten: you have a problem
12:11:50 <planetmaker> either you use last year's release version or you build it yourself
12:12:21 <rubenvincenten> alright, so I guess I'll need to build it myself then :P
12:12:23 <Ammler> well, why no simply commit the md5sum file like you have?
12:12:40 <PeterT> rubenvincenten: Ok, I'll link you to a guide
12:13:25 <PeterT> stay in IRC while you try to compile, and if you have problems just say so
12:13:43 <PeterT> I can't really help you, since I've only compilied on Linux and Windows
12:14:00 <rubenvincenten> Just to be sure: os x can't use any of the linux packages?
12:14:06 <planetmaker> Ammler: yes, it could be... for releases. But it needs thinking in what form
12:14:17 <planetmaker> rubenvincenten: no.
12:14:27 <planetmaker> it needs OSX ones
12:14:33 <planetmaker> Though the source is the same for all OS
12:17:49 <Ammler> planetmaker: just remove version from the filename
12:18:06 <Ammler> then we update the file with releases and nightlies
12:18:56 *** fonsinchen has joined #openttd
12:19:25 <Ammler> but why do you need to reproduce old releases?
12:19:27 <planetmaker> Not sure whether it's a good idea. How do you "autocommit" that?
12:19:49 <Ammler> you could just test your compile environment with current release
12:20:55 <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.
12:24:05 <planetmaker> I don't like the idea to build an md5file for every commit I make
12:25:22 <Ammler> well, I would do it only for releases
12:26:15 <planetmaker> yeah, that makes sense.
12:26:27 <planetmaker> that's one-time tasks which are managable.
12:26:31 <CIA-6> OpenTTD: terkhen * r19540 /trunk/src/station_gui.cpp: -Feature: Sort the ratings of a station by cargo class / name.
12:26:36 <rubenvincenten> When I compile for OS X, do I have to compile as a universal binary?
12:26:43 <planetmaker> rubenvincenten: no
12:26:49 <PeterT> rubenvincenten: if you are compiling for other people
12:26:50 <planetmaker> as you only compile for yourself you don't
12:27:12 <planetmaker> usually you don't want that. It doubles or tripples your compile time
12:27:31 <planetmaker> just do a ./configure && make and (hopefully) you're fine
12:28:20 <CIA-6> OpenTTD: terkhen * r19541 /trunk/src/vehicle_gui.cpp: -Feature: Sort the list of refit options by cargo class / name.
12:28:36 <planetmaker> feature-itis - day :-)
12:28:56 <rubenvincenten> Hmm, getting something about liblzo2 not found
12:29:37 <PeterT> get liblzo2, or ./configure --without-liblzo2
12:29:49 * PeterT thinks that's the correct option, but is not sure
12:30:29 *** valhallasw has joined #openttd
12:31:03 <PeterT> planetmaker would know where to get it
12:31:37 <planetmaker> either from the official website or via macports
12:31:57 <planetmaker> rubenvincenten: also: you need not necessarily worry about liblzo2
12:33:56 <PeterT> glx: IPv6 hostnames are funny-looking
12:34:27 <SpComb> IPv6 hostnames look exactly the same as IPv4 hostnames
12:34:27 <PeterT> Your logic is flawed since you haven't met me
12:36:47 <Alberth> did you meet that IP address?
12:37:56 <rubenvincenten> Hmm, compiling stuff is fun
12:38:28 <PeterT> Alberth: you got me there
12:41:21 <rubenvincenten> hmm, lzo/lzo1x.h: not found, then lzo_version)string not declared in this scope
12:41:38 <rubenvincenten> guess I need to install lzo 1 also then
12:48:05 <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?
12:48:21 <PeterT> please, ask planetmaker
12:48:25 <PeterT> I don't know Mac stuff
12:48:51 <PeterT> I just (vaguely) know libllzo2
12:51:11 *** ajmiles has joined #openttd
12:51:46 <Eddi|zuHause> likely the ./configure script needs updating so that it searches in the macports path
12:53:46 <Ammler> rubenvincenten: afaik, you need lzo only for old saves, so just compile without
12:53:58 <Ammler> and fiddle with lzo, if you really need it
12:54:07 <andythenorth> rubenvincenten: hmmm....I can compile trunk for Mac without lzo right now. Dunno why
12:54:30 <rubenvincenten> well I do have some old saves, so I like to do it the right way
12:54:35 <andythenorth> I have lzo via macports, but AFAIK it's not in the search path (it never worked previously)
12:55:18 * andythenorth compiles now to see Terkhen's sorting feature :)
12:55:18 <Ammler> rubenvincenten: ttd saves...
12:55:43 <PeterT> andythenorth: you could be the mac developer
12:55:50 <PeterT> andythenorth: you have the will power
12:55:57 <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)
12:56:18 <Ammler> we need him to develop grphics :-P
12:56:26 <andythenorth> PeterT: what Ammler said
12:56:38 <andythenorth> I'm busy making graphics all the hours I'm allowed to be :P
12:57:28 <andythenorth> plus, I'm a hacker not a programmer
12:58:06 <planetmaker> blathijs: yes, it's on my list. But the next release will take a bit ... and probably is 0.3 then :-)
12:58:45 <planetmaker> But expect to find it in some of the next nightlies. Just now I need to go out shoot some photos ;-)
12:58:52 * andythenorth is somewhat underwhelmed by the bros april fools joke :P
13:02:20 <rubenvincenten> now I'm getting something about "_FILE_OFFSET_BITS" is not defined
13:03:23 <andythenorth> you might need planetmaker to help
13:03:27 <andythenorth> I'm using leopard
13:04:00 <rubenvincenten> also, stuff like /opt/local/include/lzo/lzodefs.h:434:6: warning: "LZO_OS_DOS16" is not defined
13:04:17 *** ajmiles2 has joined #openttd
13:04:34 *** Wizzleby has joined #openttd
13:05:02 <planetmaker> rubenvincenten: I do get that, too. It surfaced with my last update of some things at macports
13:05:11 <planetmaker> it's also not critical. Albeit not nice.
13:05:19 <blathijs> planetmaker: In a nightly is fine, I'll just backport the patch
13:05:41 <planetmaker> blathijs: why backport? Do you need that for a release?
13:05:55 <rubenvincenten> planetmaker: figured that, just checking to be sure.
13:06:47 <planetmaker> rubenvincenten: I *think* it's a macports issue. One might consider to file a bug report there.
13:06:53 <blathijs> planetmaker: It sorta breaks my build (it cleans before it builds, so the md5 check doesn't happen)
13:07:10 <blathijs> planetmaker: I could also just use "make clean" for now, some extra clutter isn't really a problem
13:07:19 <planetmaker> blathijs: but clean doesn't remove the md5
13:07:30 <blathijs> planetmaker: I'm calling mrproper now
13:08:15 <blathijs> But I guess I'll just use make clean for now, so no hurry :-)
13:09:35 <rubenvincenten> andythenorth: Yeah I googled that topic, my config command was ./configure --with-liblzo2=/opt/local/lib/liblzo2.a --CFLAGS=-I/opt/local/include
13:10:01 <andythenorth> how do I find out if my compile used liblzo2?
13:10:08 <andythenorth> Terkhen: cargo sorting == win
13:10:27 <andythenorth> way more useable
13:10:46 <andythenorth> now just to show the cargo icons in lists...
13:14:00 <Alberth> andythenorth: does ldd openttd work?
13:15:29 <Alberth> ldd should display the libraries it dynamically loads
13:17:17 <Wizzleby> I always find the output of lddtree a bit easier to grok though
13:18:22 <OwenS> Many systems don't have lddtree
13:19:16 <Eddi|zuHause> that's what ldd tells me: liblzo2.so.2 => /usr/lib/liblzo2.so.2 (0xb7d37000)
13:19:33 <OwenS> Incidentally, I wonder why /opt/sunstudio12.1/bin/CC links to libsmbios.so.1...
13:20:51 <Eddi|zuHause> what package is lddtree in?
13:20:57 <blathijs> planetmaker: The same problem also applies to opensfx, btw. Can you fix that as well, or should I bug somebody else about that?
13:21:25 <Eddi|zuHause> blathijs: i'm fairly sure he's the right person to bug :)
13:21:38 <blathijs> Eddi|zuHause: Good :-)
13:21:54 <blathijs> Saves me explaining everything to somebody else as well :-p
13:22:34 <blathijs> planetmaker: Ah, now I'm using "make clean", and "make check" gets run properly it seems :-)
13:22:58 <OwenS> Eddi|zuHause: I imagine, if it exists, its in SUNWlddtree ;-)
13:23:13 <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
13:23:39 <blathijs> Yup, if I change an nfo file, I get a checksum mismatch
13:23:42 <blathijs> so it really works :-p
13:31:09 <OwenS> Hmm... Since when was the OpenTTD toolbar centered?
13:31:26 <Yexo> there is a setting for that
13:31:35 <Yexo> I think the default was changed to centered between 0.7 and 1.0
13:31:58 <Yexo> Ammler: those are invalid
13:32:04 <OwenS> Aah, so my config is still left, but the new install on the OpenSolaris box is defaulting to centered
13:33:09 <Ammler> gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
13:35:00 <Ammler> ok, thanks and sorry :-)
13:45:23 <OwenS> Hmm... Does OpenTTD's blitter ever read what it has written to the screen?
13:48:10 <OwenS> (The reason is that I'm pondering an 8bpp-opengl blitter, and if it does any readback is rather important)
13:52:18 <blathijs> I think there have been a few attempts at OpenGL blitters before, IIRC there were problems with that
13:52:47 <blathijs> But it might be that the entire blitter-thing has been restructured since then
13:53:12 <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
13:53:34 <OwenS> Primarily for hardware without hardware 8bpp support (Emulating it using a fragment shader)
13:54:21 <rubenvincenten> Hmm I seem to be missing the option to show a station's reach (to see what the best placement is)
13:56:06 <Alberth> in the station picker window you can toggle the rectangle (just above the cargoes)
14:03:46 <Alberth> hmm, it is so basic, our wiki doesn't even mention this
14:08:33 <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.
14:08:52 <planetmaker> they all more or less share the same basic makefile
14:09:53 <planetmaker> hopefully actually "more" :-)
14:10:16 <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?
14:11:19 <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?
14:11:22 <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.
14:12:31 <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.
14:12:38 <Yexo> would something like bool AICargo::IsAcceptedBYSomeHouse(CargoID) be useful?
14:13:04 <planetmaker> Zuu: houses can accept any carge the newgrf author wishes
14:13:06 <Alberth> wouldn't you have to find a place for it anyway?
14:13:18 <planetmaker> today is my typo day
14:13:34 <Yexo> Alberth: yes, but if you know no house accepts a cargo you don't have to scan towns for it
14:13:50 <Yexo> if there is at least one housetype that accepts that cargo, then you'll have to scan all towns for a suitable location
14:14:03 <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.
14:14:03 <blathijs> planetmaker: Thanks! :-)
14:14:17 <Alberth> then make perhaps it more useful and return a search area?
14:14:39 <Yexo> Alberth: what kind of search area?
14:14:46 <planetmaker> blathijs: generally, if something doesn't work (or works) for one project, chances are very good it's the same for the other
14:14:49 <Alberth> for a place to put the station down
14:15:10 <Yexo> that is up to the AI, not the API
14:15:43 <Yexo> besides, what kind of area would you return for normal passengers? a disjoint set over all towns on the map?
14:15:55 <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.
14:16:00 <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?
14:16:23 <Yexo> Alberth: I wasn't suggesting to search the town
14:16:31 <Yexo> only looping over all house types
14:16:45 <Yexo> searching a town would mean looping over the complete map I think
14:17:25 <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.
14:18:10 <Alberth> the question is , what happens when you do have a matching cargo
14:18:26 <Yexo> then you'll have to search for a good location anyway, just like you have to now
14:18:39 <Zuu> Then I wolud have to scan towns that are close enough to be intresting and see if they accept the cargo.
14:18:56 <Alberth> 'scan towns' is the whole map, it seems
14:19:22 <Yexo> most AIs limit the region to center of town +- 20,20
14:19:28 <Yexo> or a similar value depending on the town size
14:19:55 *** PeterT_ has joined #openttd
14:21:06 <Eddi|zuHause> Zuu: but humans also don't check the whole map
14:21:22 <Eddi|zuHause> they first check all industry types, and then all house types
14:21:23 <Alberth> so the answer from the new api call is not the same as what AIs do next
14:22:09 <Yexo> indeed, it's only an optimization so AIs know they can skip the next step
14:23:04 <Zuu> As AIs can't neither read the NewGRF manual or look at the graphics to get such clues.
14:36:48 *** KillaloT has joined #openttd
14:45:23 <Eddi|zuHause> that's the entire core of the problems: newgrfs have no measures to give hints to ais
14:47:32 <glx> theorically there are callbacks for that, but IIRC not very usable for NoAI
14:48:32 <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)
14:48:53 <Yexo> only cb I know of is cb 18, which is only for building engines / stations
14:49:06 <Yexo> * only ai-related callback
14:49:14 <OwenS> **since it was created last year
14:49:35 <glx> Yexo: as I said not very usable ;)
15:06:37 <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.
15:07:25 <Zuu> Apart from looping over all industries and hope that there is a AITileList_Industry class.
15:09:46 <Yexo> there is no AITileList_Industry class either
15:09:54 <Yexo> so it's completely impossible I think
15:10:23 <Eddi|zuHause> why does that even matter?
15:11:09 <Yexo> it it's accepted by an industry you can keep track of that industry and close down the route when that industry closes
15:11:25 <Yexo> if it's part of a town you'll have to check regurarly if the station still accepts the cargo
15:11:48 <Zuu> And town and indistries use different API calls, so it is quite important to keep track of.
15:11:53 <Eddi|zuHause> so you need something like "get all industries in catchment area"
15:12:57 <Zuu> Yep, that would be awsome.
15:13:17 <Zuu> Or even AIIndustry.GetIndustryID(tile)
15:13:32 <Zuu> Similar to the AIStation.GetStationID(tile)
15:15:02 <planetmaker> ~/Documents/OpenTTD/content_download/ai> tar tf NoCAB-2.0.0.tar
15:15:04 <planetmaker> NoCAB-2.0.0/pathfinding/pathfinderhelper.nut
15:15:05 <planetmaker> tar: Truncated input file (need to skip 1536 bytes)
15:15:07 <planetmaker> tar: Error exit delayed from previous errors.
15:15:14 <planetmaker> any idea as of the reasons?
15:15:38 <planetmaker> also a re-download won't change that
15:16:00 <planetmaker> might my mirror have a truncated file?
15:16:24 <planetmaker> also: re-download is always possible... I won't get a green bullet there
15:16:36 <Yexo> then delete the old file
15:16:40 <Yexo> after that try redownload again
15:17:02 *** ADMINtur has joined #openttd
15:17:47 <Yexo> $ md5sum NoCAB-2.0.0.tar
15:17:47 <Yexo> 7a0240def16cca9c147457d54291afe3 *NoCAB-2.0.0.tar
15:19:25 <OwenS> OpenSolaris' extended file attributes are insane
15:19:40 <planetmaker> Yexo: a re-download shows the same problem.
15:19:51 <planetmaker> also after deleting the previous 2.0.0 version
15:19:52 <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.
15:20:24 <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
15:20:24 <Yexo> planetmaker: does the md5sum match the one above?
15:20:36 <Yexo> Zuu: which FS# was it again? I'll take a look at it today
15:32:22 *** Dred_furst has joined #openttd
15:33:24 <PeterT> BaNaNaS is unually slow
15:34:47 *** |Jeroen| has joined #openttd
15:36:40 <PeterT> can we make the sound for laying track in osfx a bit louder?
15:36:51 <PeterT> in fact, many osfx sounds are quiet
15:37:32 <planetmaker> PeterT: it can be made. *someone* has to do that, though
15:37:58 <planetmaker> But I see no sound artist with a passion around. Nor have I seen
15:44:59 <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.
15:47:49 <welshdragon> planetmaker: passion isn't needed, somebody just needs to use Adobe Audition or something to make it louder
15:48:40 <Yexo> Zuu: water isn't accepted by houses normally
15:48:44 <planetmaker> yes. But *somebody* needs some passion in order to actually be the 2nd person in order to start meddling with sounds for OpenTTD
15:48:54 <Yexo> in the desert climate it's accepted by water towers (=an industry)
15:49:26 <Zuu> oh, yea total mind loss :-)
15:52:27 <Eddi|zuHause> MB once said he has a house set that accepts coal
15:52:30 <planetmaker> unless again someone defines houses which accept it ;-)
15:52:51 <Eddi|zuHause> (and shows smoke animation if coal was delivered recently)
15:53:20 <planetmaker> it will be released right after dbxl 1.0
16:02:14 <planetmaker> hm... any way to find out which bananas mirror I use?
16:03:16 *** ChanServ sets mode: +v tokai
16:06:57 *** TheMask96 has joined #openttd
16:07:03 <peter1138> heh, 1.0.0 release certainly increased traffic somewhat
16:15:12 <Eddi|zuHause> planetmaker: look how binaries.openttd.org redirects you?
16:15:41 <Eddi|zuHause> assuming the load balancing mechanism works the same way
16:16:34 <planetmaker> hm... NoCAB isn't yet synced...
16:17:15 *** Grelouk has joined #openttd
16:17:18 <planetmaker> do you get a working download of NoCAB 2.0.0? I assume so...
16:38:39 <Terkhen> planetmaker: I downloaded NoCAB 2.0.0 two hours ago
16:38:53 <planetmaker> I assume no problems, eh?
16:41:38 <planetmaker> hm. The version from the forums works fine for me, too
16:43:47 *** Biolunar has joined #openttd
16:46:15 <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.
16:46:20 * andythenorth stares glumly at some very wrong offsets for ships :|
16:48:06 <planetmaker> o/ graph scaling!
16:48:17 <planetmaker> Terkhen likes features ;-)
16:51:40 <Terkhen> it is really a mix of feature and fix
16:52:35 <Eddi|zuHause> somehow my antenna is slightly misaligned
16:53:00 <Eddi|zuHause> i get small but annoying image errors in my night recordings
16:53:08 <Eddi|zuHause> during the day it's fine, apparently
16:53:18 <Terkhen> I have finished for now... time to test :)
16:59:56 *** fonsinchen has joined #openttd
17:03:48 *** yarikos has joined #openttd
17:04:44 <yarikos> i've got 1.0 dmg for osx 10.5. anybody interested?
17:07:46 <Zuu> planetmaker: I downloaded NoCAB yesterday I think (or if it was this morning)
17:08:15 <planetmaker> ok, so it's really me.
17:09:16 <planetmaker> who knows. But the mirror doesn't have it, if I look at binaries.openttd.org
17:09:27 <planetmaker> so we all should get it from the main server
17:14:51 <planetmaker> yarikos: you could post it in tt-forums...
17:17:04 <yarikos> does it requires a kind if registration?
17:17:30 <planetmaker> besides compilation is not the issue the macport has.
17:20:11 <planetmaker> hm... universal compile takes ages :-P
17:20:34 <yarikos> i've taken svn tags/1.0.0 - it compiled without any troubles (i didn't try the universal build)
17:21:30 <planetmaker> he... I cannot produce them.... linker failure.
17:21:33 <yarikos> btw, does anybody still need lzo2 support? i've compiled without it
17:21:39 <planetmaker> I don't have universal libraries
17:23:07 <planetmaker> possibly the trunk intro savegame
17:23:51 <yarikos> miniLZO is not enought, is it?
17:25:02 <Eddi|zuHause> yarikos: it used to use minilzo, but that caused too many maintenance troubles
17:25:18 <aber> what looks the start screen like without lzo2, just water?
17:26:08 <Eddi|zuHause> aber: the 1.0.0 start screen is a new savegame, it should not be affected
17:26:10 <yarikos> with opengfx the start game is o.k.
17:26:24 <planetmaker> of the 1.0 branch. That's another start game than trunk has
17:26:47 <Eddi|zuHause> i don't know if the old one is...
17:27:01 <planetmaker> Also the graphics set used has no influence on whether a game can be loaded... at least it should :-)
17:27:35 <yarikos> then, it is o.k. as for 1.0
17:27:53 *** ccfreak2k has joined #openttd
17:28:03 <planetmaker> Well. Using 1.0 doesn't mean one doesn't try to load an old savegame
17:28:14 <planetmaker> But ... in 99.95% it shouldn't matter
17:28:53 <yarikos> i'm already building liblzo
17:29:44 <planetmaker> seems like the bigger challange is anyway to get all those required libs as universal libs
17:30:55 <planetmaker> liblzo2, libpng, libfreetype, libicu*
17:31:23 <aber> you should use boost, then its like a 24h burn in test...
17:31:36 <aber> libicu is broken, at least for me...
17:34:59 <planetmaker> define 'broken' :-)
17:35:33 <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)
17:35:42 <aber> +universal (i386 x86_64 ppc) does not install
17:35:47 <Yexo> Zuu: some comments: don't use DoCommand from gui code, use DoCommandP instead (or it'll break in multiplayer)
17:36:02 <Yexo> only place pause mode is changed is in CmdPause
17:36:50 <Zuu> Okay. IIRC I was fiddling around with both DoCommand and DoCommandP until I got something that worked.
17:37:18 <Zuu> Thanks for taking your time to get it in.
17:37:32 <Yexo> thanks for the nice patch :)
17:37:59 <yarikos> src/crashlog.cpp:167:23: error: lzo/lzo1x.h: No such file or directory
17:38:23 <yarikos> (JFYI, i'm working it around)
17:42:34 <Zuu> Yexo: I found a typo in one comment of the code that you commited, probably my fault "matchding" should of course be "matching".
17:42:55 *** Alberth1 has joined #openttd
17:42:55 *** Alberth is now known as Guest1054
17:42:55 *** Alberth1 is now known as Alberth
17:43:37 <CIA-6> OpenTTD: yexo * r19545 /trunk/src/ai/ai_gui.cpp: -Fix (r19544): typo
17:43:45 <Yexo> I added those comments, it wasn't your fault
17:44:35 <yarikos> shouldn't 3rd party libs find its way to ottd sources so there would be no need to pull threads from the world
17:45:26 <CIA-6> OpenTTD: translators * r19546 /trunk/src/lang/ (french.txt korean.txt spanish.txt):
17:45:26 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
17:45:26 <CIA-6> OpenTTD: french - 4 changes by glx
17:45:26 <CIA-6> OpenTTD: korean - 2 changes by junho2813
17:45:26 <CIA-6> OpenTTD: spanish - 5 changes by Terkhen
17:45:49 <planetmaker> yarikos: why should 3rd - party stuff in the openttd repo, if it can be pulled from their original source?
17:46:09 * Alberth consider adding X11 source code
17:46:27 <planetmaker> it would be nice to have that in an SDK, though :-)
17:46:51 <planetmaker> but then... that would need maintenance. And building static binaries. Not necessarily good.
17:47:35 <Alberth> most linuxes have a packagemanager that can install the 3rd-party libs, if it didn't already do so when installing the OS.
17:47:36 <yarikos> what's bad with static linking at least against -licu -lpng -llzo2?
17:48:04 <Alberth> how is that helping you in building a binary yourself?
17:48:08 <planetmaker> add to that doing that 3 times for universal ones.
17:49:14 <planetmaker> aber: the usual universal binaries have intel, ppc and ppc-g5
17:50:46 <Zuu> doesn't the intel work on amd64?
17:50:54 <glx> planetmaker: they can have ppc64 and x86_64 too
17:50:55 <yarikos> i would't like to start another dynamic-vs-static wars here
17:51:24 *** fonsinchen has joined #openttd
17:51:52 <yarikos> however, i came from plan9 world were we depend on just one thing in runtime: the kernel
17:51:53 <hron84> after i start openttd that message appears
17:51:56 <planetmaker> hron84: update. Both OpenTTD and AI
17:52:06 <Zuu> hron84: What OpenTTD version do you run?
17:52:25 <Zuu> 0.7.5 should work also I think
17:52:26 <hron84> but it masked under gentoo
17:52:50 <planetmaker> hron84: so? Just download the binary and run it in your user dir.
17:52:59 <yarikos> any hints on getting liblzo compiled universal?
17:53:08 <Zuu> hron84: Do gentoo allow you to upgrade to 0.7.5 (or 0.7.4)?
17:53:09 <planetmaker> yarikos: no idea. I just looked myself
17:53:29 <yarikos> should we bother with universal at all?
17:53:37 <hron84> Zuu: wait, i update package infos, i hope 0.7.5 is placed under stable arch
17:53:41 <Zuu> 0.7.5 should be ok to solve your problems.
17:53:43 <glx> I had no problems to compile macports liblzo2 IIRC
17:54:01 <glx> <yarikos> should we bother with universal at all? <-- yes
17:54:02 <hron84> but my network is little slowy
17:54:06 <Zuu> Still I wolud rather upgrade to 1.0.0 and have all the last features :-)
17:54:13 <planetmaker> yarikos: well... that does make sense. But actually only when one tries to fix all OSX bugs
17:54:19 <glx> many OSX users don't now the type of their CPU
17:55:34 <yarikos> glx: true. most time it's idling
17:55:53 <Zuu> hron84: too slow for a 3-4 MB binary?
17:56:12 <hron84> not, slow for update my gentoo package infos
17:56:23 <Zuu> or get the 1.0.0 sources of I don't know how big they are.
17:56:26 <hron84> i don't like install anything out of package manager
17:56:50 <glx> it's not an install, it's just an extract in home dir
17:56:59 <Zuu> You don't need to install OpenTTD in /usr, you could install it in your home dir as glx just said.
17:57:17 <planetmaker> not even install actually. Just unzip
17:57:37 <glx> planetmaker: you're slow ;)
17:57:41 <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.
17:57:54 <hron84> and the closed files are still needed?
17:58:13 <Zuu> If you refer to the TTD data files.
17:58:14 <planetmaker> Haven't been really for 0.7.x neither...
17:58:35 <hron84> btw, is there a 64 bit binary?
17:58:42 <Zuu> Indeed you could play 0.7.x soundless with the free graphics.
17:59:14 <planetmaker> hron84: just visit the download location...
17:59:35 <Zuu> Indeed, see the Linux Generic Binaries.
17:59:50 <Zuu> There you have x86_64, 64bit
18:01:19 <glx> and generic are statically linked I think
18:01:32 <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.
18:01:52 <yarikos> seems i have to kill liblzo sources and get it installed via macports (which i have to have installed before)
18:03:27 <yarikos> no, thanks, that's too much for my 3G carried data plan
18:04:09 <yarikos> so I'll make intel-only but with lzo
18:05:32 <planetmaker> yarikos: if you have the liblzo sources you can install them manually, too.
18:05:46 <planetmaker> Just producing universal libs... is difficult :-)
18:06:01 <planetmaker> but then... macports is easy
18:07:13 <yarikos> planetmaker: i've got the sources. still, i don't see what and where to do to make it universal
18:07:47 <planetmaker> yarikos: yes, me neither. But if you worry about your download plan, you could install from that source
18:07:56 <planetmaker> a non-universal one
18:08:41 <yarikos> that's what i'm doing.
18:09:11 <yarikos> which libicu to pick up?
18:10:32 <yarikos> 15M lib? what did they put in there?
18:10:47 *** Zephyris has joined #openttd
18:11:40 <yarikos> i'll try with icu4c 4.4
18:12:05 <PeterT> Zuu: congrats on patch in trunk
18:14:01 <Zuu> Go and test the filter sign list patch and I can probably soon suggest it too. ;-)
18:14:35 <yarikos> planetmaker, where should i proceed when I got intel-only dmg with the bits in? forum? I could upload on sf.net
18:16:32 <planetmaker> you'll not be the first with that on SF.
18:16:52 <planetmaker> there's a openttdformac "project" or so
18:17:46 <yarikos> ah, sorry, ottd is hosted elsewhere
18:17:59 <PeterT> *what am I testing for?
18:18:21 <Yexo> yarikos: compiling a mac binary has never been the problem, supporting it (and as such fixing the mac-specific bugs) is the problem
18:18:28 <Yexo> that's the reason there are no mac binaries on openttd.org
18:18:47 <Zuu> See if it acts strange. Eg when you search for signs.
18:19:03 <Zuu> mixing between using keyboard or mouse.
18:19:05 <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
18:19:48 <PeterT> oh good, #openttdcoop hasn't updated yet
18:19:57 <PeterT> that means I can still use the binary you've provided
18:20:08 <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?
18:21:40 <yarikos> anyway, when i'll come up with a dmg, i'd like to share it with the world.
18:22:35 <PeterT> Zuu: You said you changed the GUI to be like the Town window or somethign?
18:22:47 <PeterT> I don't see a big difference
18:27:36 *** devilsadvocate has quit IRC
18:31:54 *** Adambean has joined #openttd
18:35:50 *** fonsinchen has joined #openttd
18:37:14 <PeterT> I can confidently suggest that Filter Sign List be introduced into trunk
18:37:23 <PeterT> Zuu and I are testing it
18:39:14 <planetmaker> PeterT: shouldn't the suggestion for inclusion be at the end of a successful test? ;-)
18:40:51 <PeterT> planetmaker: So far, so good
18:50:05 <Seki> Is there a list of default building IDs somewhere, like there is for vehicles?
18:50:38 <Yexo> or what kind of buildings?
18:51:08 <Seki> I kept searching for "building" ids. Thanks :)
18:59:58 <yarikos> the forum doesn't support OpenIDs, does it?
19:04:48 *** lobstah has joined #openttd
19:07:06 <Alberth> Hmm, I seem to have switched from editing source to editing diffs. Not sure that is a step forward :p
19:08:53 <Zuu> or makning diffs of diffs..
19:10:57 <Eddi|zuHause> i don't think "meta-programming" was meant like this :p
19:14:06 <Alberth> Zuu: you get those when you put your patches under version control, still struggling to read those without getting confused.
19:23:29 <Eddi|zuHause> diff-editing is sometimes useful to apply old patches
19:23:52 <Eddi|zuHause> e.g. when they only conflict on some variable renaming
19:24:07 *** Progman has joined #openttd
19:27:07 *** Brianetta has joined #openttd
19:28:54 <yarikos> ok, i've got the dmg (intel-only)
19:31:07 *** devilsadvocate has joined #openttd
19:33:58 <OwenS> Mmmh.... Belgian chocolate
19:48:11 * TrueBrain concratz #openttd with its 20,000 download of 1.0.0
19:48:27 <ddfreyne> OwenS: belgian chocolate is awesome :)
19:48:52 <PeterT> TrueBrain: already? wow
19:49:35 <planetmaker> that's quite awesome :-)
19:49:45 <Ammler> 19500 windows downloads :-)
19:50:01 *** lobstar has joined #openttd
19:50:08 <planetmaker> TrueBrain: do you have stats on how many of those downloaded also Open[G|S]FX?
19:50:31 <TrueBrain> planetmaker: all I can tell atm is that there were 60,000 downloads for BaNaNaS
19:50:47 <planetmaker> hm... I'd be interested in those of 1.0.0, though.
19:50:58 <planetmaker> The bananas download stats are accessible to me.
19:51:11 <planetmaker> but not the installer.
19:51:19 *** Biolunar has joined #openttd
19:51:25 <planetmaker> (stats of OpenGFX to be exact. not general bananas)
19:52:16 <Ammler> hmm, dunno anymore, do you need mark opengfx for download
19:52:16 <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 :)
19:52:38 <Ammler> or would you need to unmark those for not downloading?
19:52:59 <Rubidium> it doesn't track the installer directory
19:54:00 <Zephyris> Is there a way to get a time breakdown of a bananas file? That would be very interesting to see...
19:54:25 <Zephyris> Meanings downloads of course...
19:54:28 <Rubidium> Zephyris: not for you; we got the data though
19:54:52 * planetmaker is part of the big 99.2% horde
19:55:03 <Rubidium> Zephyris: I hope you meant some sort graph showing how many were downloaded at a specific date
19:55:25 <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)
19:55:29 <planetmaker> Rubidium: I guess somthing like n(t)
19:55:42 <Eddi|zuHause> they should have turned off the internet to introduce ipv6, like they announced :p
19:55:50 <planetmaker> would indeed be interesting :-)
19:56:18 <TrueBrain> planetmaker: today alone, I count 6965 redirects for installer files
19:56:33 <planetmaker> TrueBrain: thanks :-) Sounds like a bit :-)
19:56:49 <TrueBrain> yesterday I count 10k
19:57:01 <planetmaker> ok... that was easy :-P
19:59:10 <TrueBrain> 2338 opengfx, 2304 opensfx :p
19:59:32 <planetmaker> that's somewhat less than 7k
20:00:03 <TrueBrain> I assumed you could do that math yourself :p
20:00:10 <Rubidium> i.e. pretty damn close
20:00:27 <Rubidium> @calc 6965-2338-2304
20:00:51 <Rubidium> people still download that?
20:00:58 <Rubidium> that's like 1.0.0-beta era
20:02:58 <TrueBrain> so people still download that :p
20:04:22 <Ammler> that is only 10% downloading the open base sets?
20:04:40 <planetmaker> hm... that's not a lot then.
20:05:10 <TrueBrain> @calc (5227 + 8686) / (4079 + 6631)
20:05:10 <DorpsGek> TrueBrain: 1.29906629318
20:05:15 <TrueBrain> @calc (4079 + 6631) / (5227 + 8686)
20:05:15 <DorpsGek> TrueBrain: 0.769783655574
20:05:35 <TrueBrain> 76% of the downloads so far is Windows, so sorry Ammler ;)
20:06:00 <planetmaker> add the 1k downloads from bananas and the downloads from the devzone, but...
20:06:06 <Zephyris> Rubidium: a graph of downloads would be amazing!
20:06:11 <planetmaker> TrueBrain: what does that have to do with base set usage?
20:06:23 <Rubidium> Zephyris: and computationally very expensive
20:06:24 <TrueBrain> planetmaker: I was not talking about that, don't know what you were talking about
20:06:33 <TrueBrain> I was just commeting on that Ammler said that 19500 were Windows :p
20:07:27 <TrueBrain> @calc (821 + 1326) / (5227 + 8686)
20:07:27 <DorpsGek> TrueBrain: 0.154316107238
20:07:33 <TrueBrain> 16% Linux .. nice ..
20:07:46 <Rubidium> primarily because there are no indices on the stats table (and it's 8+ million entries long)
20:07:58 <Ammler> with the fact that most linuxer uses distro repos...
20:08:03 <TrueBrain> Rubidium: I should really write that new stats idea ;)
20:08:12 <Rubidium> TrueBrain: yeah, you should :)
20:08:57 <TrueBrain> @calc 1841491 / 24 / 3600
20:08:57 <DorpsGek> TrueBrain: 21.3135532407
20:09:00 <OwenS> Or just add indexes tro the stats table?
20:09:02 <TrueBrain> 21 hits per second .....
20:09:21 <TrueBrain> (normal we run at 7 hits per second)
20:09:31 <Rubidium> OwenS: would make the table IIRC 8 times bigger
20:09:47 <OwenS> Rubidium: What database & storage engine?
20:10:07 <Rubidium> don't know the storage engine, but I guess it's the default one
20:10:10 <TrueBrain> doesn't really matter. How we store the data is just very inefficient
20:10:24 <OwenS> I suppose a count of each "property" would be smarter? :p
20:10:34 <OwenS> Though couldn't do correlations then
20:10:53 <TrueBrain> that is what should be done
20:11:14 <Rubidium> OwenS: you mean only counting how often a particular file is downloaded?
20:12:21 <Rubidium> anyhow, the table just stores the file is and a date
20:12:42 <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"
20:13:07 <Rubidium> OwenS: but that's useless for bananas stats
20:13:23 <Rubidium> you're not talking about TB's proposal, right?
20:13:37 <OwenS> Rubidium: I hadn't had chance to read it when I said what I did ;p
20:14:10 <Rubidium> but bananas stats is just (file_id, date)
20:14:23 <OwenS> InnoDB would probably be smaller. Or perhaps BDB
20:15:04 <TrueBrain> wouldn't really matter. What we store is just very inefficient
20:15:22 <Rubidium> doubtful; it says a record is 13 bytes, 8.5 million records -> 105 MiB
20:15:42 <OwenS> I was refering to InnoDB or BDB's indexes
20:15:49 <TrueBrain> if you store 1 record for every download, there is just no way to store it efficiently :p
20:16:45 <Rubidium> download stats just store file, "hour", count and has 0.25 million records
20:17:07 <Rubidium> for 1.2 million downloads
20:17:36 <Seki> Random question: Does delivering goods to a town actually help it grow?
20:18:03 <planetmaker> doesn't. unless it's one of 5 serviced stations.
20:18:21 <Seki> Hmm, should the Wiki not say it does, then?
20:18:40 *** devilsadvocate has quit IRC
20:19:06 <Eddi|zuHause> Seki: it's a very sticky myth, those are difficult to keep out of wikis
20:19:32 <Seki> Eddi: That makes sense, then. Thanks for the clarification.
20:19:59 <Eddi|zuHause> Seki: please edit it out of the wiki page you read :)
20:20:30 <Eddi|zuHause> or better: specifically say the opposite :)
20:21:03 <Seki> That was the plan - before I edit it: Food?
20:21:29 <Seki> Does it speed town growth, other than as a requirement for desert/snow towns to grow
20:22:52 <Seki> As updating on wiki: Delivery of Goods or Food has no effect on the speed of town growth.
20:22:58 <Eddi|zuHause> Seki: the only thing that counts (other than the requirements) is serviced stations. which cargo is transported is irrelevant
20:23:44 *** Zephyris has joined #openttd
20:24:10 *** Rhamphoryncus has joined #openttd
20:42:46 *** Zephyris has joined #openttd
21:00:28 *** Nite_Owl has joined #openttd
21:07:55 *** Terkhen has joined #openttd
21:09:32 *** rubenvincenten has left #openttd
21:12:29 * andythenorth needs an offset editor
21:13:05 <Zuu> hm, the tool that glx or some other dev made do not offer that?
21:13:29 <blathijs> planetmaker: lintian complains about the .hgtags file in the source tarball
21:13:35 <blathijs> planetmaker: I guess that shouldn't be in there?
21:14:21 <planetmaker> well... it needn't, yes
21:14:43 <planetmaker> I simply defined "source" as "whatever is tracked"
21:15:02 <planetmaker> and only started to add exceptions :-)
21:15:27 <blathijs> It's sort of a metadata file that IMHO doesn't even belong inside a repository anyway, but well :-p
21:15:46 <blathijs> planetmaker: Would it be easy to remove it? Now I have a lintian warning :-)
21:15:49 <Rubidium> blathijs: it happens with all distributed VCSes I know
21:16:02 <planetmaker> blathijs: in the tar ball: yes
21:16:08 <planetmaker> but it must be part of the repo
21:17:07 <blathijs> planetmaker: Yeah, that's fine. I won't ask you to fix (what I consider) deficiences in hg :-p
21:17:18 <blathijs> Rubidium: Uh, git just stores tags in the .git directory
21:17:33 <blathijs> Rubidium: This is about tags, not ignore
21:17:37 <planetmaker> blathijs: that's no deficiency. How else would you handle tags in a _distributed_ VCS?
21:17:39 <Rubidium> blathijs: but not .gitignore
21:17:50 <Rubidium> which is *also* metadata
21:18:00 <blathijs> planetmaker: Like git does?
21:18:12 <planetmaker> how does it do it?
21:18:18 <planetmaker> How do others know about tags?
21:18:31 <blathijs> planetmaker: Just store them in the .git directory and push and pull them as part of the git protocol
21:18:39 *** hron841 has joined #openttd
21:18:54 <blathijs> Rubidium: I think .gitignore is less ugly, but that's probably only because I'm used to it :-p
21:19:21 <planetmaker> blathijs: yes... but what's the difference to a .hgtags file now? I see no difference really.
21:19:57 <blathijs> planetmaker: That the .hgtags file is now part of the _content_ of the repository
21:20:32 <blathijs> If I really wanted to put a file called '.hgtags' in my repository, I can't, because that name is special
21:20:49 <blathijs> And if I do an export of a repository, I get that file as well
21:21:09 <blathijs> But these reasons really mean that .gitignore is ugly as well :-)
21:21:43 <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
21:26:12 *** Grelouk has joined #openttd
21:30:50 *** Kurimus has joined #openttd
21:31:00 <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
21:32:34 <Eddi|zuHause> did you mean "action 8"?
21:32:47 *** devilsadvocate has joined #openttd
21:32:58 <Rubidium> that would be too obvious
21:34:04 <Yexo> Eddi|zuHause: no, property 08
21:34:28 <Yexo> maybe I should've mentioned it it's only for houses, industries and industry tiles
21:35:20 <Eddi|zuHause> ah, so it's something entirely different than i thought
21:41:38 <Yexo> reading the FS task should make it more clear
21:42:36 *** andythenorth has left #openttd
21:47:14 <blathijs> Rubidium: I guess the "attempt to free a non-heap object" warnings were already known?
21:47:42 <Rubidium> blathijs: did you look at the code causing it?
21:47:47 <blathijs> IIRC you reported that as a gcc bug, or didn't you?
21:48:06 <blathijs> No, I just saw the warnings fly by
21:48:19 <blathijs> Then I did look at the code, a while ago :-)
21:48:27 <Rubidium> and it's bogus as described in readme.txt and the code
21:48:39 <Rubidium> it only "happens" when compiling without assertions
21:49:04 <Rubidium> as the assertion for some reason makes GCC not notice it
21:54:18 <Rubidium> "kweet niet hoe het kan, maar profiteer er van" :)
22:22:15 <Zuu> Hmm, the Land Area info window do not refresh when you change language.
22:28:24 <Yexo> Zuu: it won't update either if the tile you clicked is changed
22:29:00 *** welshdragon has joined #openttd
22:29:50 <Zuu> Ok, noticed that it does change the title, but not the contents. Guess the window simply don't store the tile.
22:30:51 <Yexo> the title is just a StringID, like most strings used in windows
22:31:03 <Yexo> the contents of that window are an exception, they're stored as C-strings
22:35:57 <Rubidium> there are simply too many corner cases with the window that updating it each tick is worth it
22:36:27 <Rubidium> for one we'd need to hook into *all* and *every* map accessor that changes the map
22:36:40 <Rubidium> so we can tell the window to update when needed
22:36:51 <Rubidium> which means lots of trouble
22:37:34 <Rubidium> also storing the non-resolved strings isn't an option because then it'll crash when removing some stuff (towns, stations, companies, ...)
22:42:43 <Zuu> What does the "mark" button at webtranslator does? Does it mark the translation validated?
22:43:18 <Rubidium> no, it marks it so it gets into the "strings needing validation" group
22:43:21 <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?
22:43:54 <Rubidium> those are strings that changed in English or strings that were marked by other translators
22:45:05 <Zuu> And to validate a string you (after having checked that the translation is ok) click on the save button?
22:45:30 <Zuu> Sorry for asking, but can't find this documented at the faq/wiki
22:50:12 *** R-Blade has joined #openttd
23:28:57 *** ragzid is now known as ragzid|ZzZz
23:59:27 *** Eddi|zuHause has joined #openttd
continue to next day ⏵