IRC logs for #openttd on OFTC at 2010-05-17
⏴ go to previous day
00:05:11 *** last_evolution has quit IRC
00:07:11 <Eddi|zuHause> potrzebie: that suggestion pops up every now and then, but it's just an unusable solution
00:08:43 <Eddi|zuHause> potrzebie: imagine 3 cities A,B,C with bus service city<->airport and 3 airlines A<->B, B<->C and C<->A, each airline has orders "transfer and don't load cargo again you just unloaded"... still passengers can circle A->B->C->A this way
00:10:26 <Eddi|zuHause> potrzebie: the only real solution is cargo destinations, but the current implementations of that are not stable enough yet
00:20:02 *** theholyduck has joined #openttd
00:21:56 *** theholyduck has joined #openttd
00:24:50 *** theholyduck has joined #openttd
00:26:42 <potrzebie> Eddi|zuHause: Isn't it unusable only when the cargo is the same to drop off and pick up, like passengers?
00:27:25 <Eddi|zuHause> potrzebie: yes. but passengers is the most common use case of transfers by far.
00:32:09 <potrzebie> I see. So the ultimate solution, cargo destination, is coming in a near future?
00:40:37 *** theholyduck has joined #openttd
01:30:47 *** ajmiles2 has joined #openttd
01:32:48 *** xOR is now known as xOR^away
02:07:50 *** xOR^away is now known as xOR
04:56:23 *** Eddi|zuHause has joined #openttd
05:13:15 <Terkhen> TrueBrain, SmatZ, planetmaker: I live in Granada, at the southern part of Spain
05:24:31 <potrzebie> Granada, isn't that famous for something?
05:28:19 <Terkhen> most tourists come here to see the Alhambra
05:28:27 <ccfreak2k> Don't confuse it with Grenada.
05:31:08 <potrzebie> That's probably what I did.
05:38:49 *** DorpsGek has joined #openttd
05:38:50 *** ChanServ sets mode: +o DorpsGek
05:40:02 *** Hirundo_ is now known as Hirundo
06:27:22 *** lasershock has joined #openttd
06:56:49 *** Markk_ is now known as Markk
07:27:28 *** Devedse has joined #openttd
08:31:17 *** fonsinchen has joined #openttd
08:35:50 <fonsinchen> TrueBrain, could you build another version of cargodist on the CF?
08:50:48 *** JVassie has joined #openttd
08:52:57 <blathijs> Hmm, meeting in Germany, sounds nice :-)
08:53:23 <fonsinchen> I might even go there
09:00:46 <dihedral> i do not think he quite understood the difference between SERVER and CLIENT :-P
09:04:47 <Ammler> or a bug of OFTC, the network should shutdown now...
09:09:33 *** HerzogDeXtEr1 has joined #openttd
09:40:15 *** oskari89 has joined #openttd
09:56:24 *** Doorslammer has joined #openttd
10:17:08 *** Doorslammer has joined #openttd
10:17:25 *** Adambean has joined #openttd
10:20:37 *** fonsinchen has joined #openttd
10:25:50 *** Eddi|zuHause2 has joined #openttd
10:35:48 *** KenjiE20 has joined #openttd
10:38:59 *** Eddi|zuHause2 is now known as Eddi|zuHause
10:48:42 *** DX_Ipad has joined #openttd
10:57:51 *** Progman has joined #openttd
10:58:48 *** ggergely has joined #openttd
10:59:05 <andythenorth> sailing ships....variable wind?
10:59:22 <ggergely> hi. i have 3 minor portability patches fot netbsd compatibility of openttd 1.0.1. where should i send them, to get merged?
11:00:25 <Eddi|zuHause> andythenorth: if you can make it so two ships near each other get affected by similar winds, but still keep it pseudorandom
11:01:06 <planetmaker> ggergely, as fonsinchen said
11:01:39 <ggergely> i'd prefer not to register. is it a must?
11:01:51 <andythenorth> can vehicles get their xy co-ordinate?
11:02:11 <Rubidium> no, it just means we'll forget about the patches
11:02:12 <ggergely> this is what i hate about opensource. i have gazillions of forgotten bogzilla accounts around few dozen projects i use
11:02:37 <andythenorth> is there room in the map for 'wind strength'? 1 byte would be sufficient
11:02:58 <Eddi|zuHause> ggergely: but that means you have trouble organising yourself, not that buzillas are evil.
11:03:31 *** Dreamxtreme has joined #openttd
11:04:17 <ggergely> it means: why note up all accounts, if i don't remember how many patches havei submitted to millions of places. most of them never got appiles, still have to manually manage the patches for bugzillas
11:05:00 <ggergely> there was a 2liner patch that got merged after 3 years into project. usually both upstream, and i do forget about them
11:06:32 <planetmaker> <ggergely> this is what i hate about opensource. i have gazillions of forgotten bogzilla accounts around few dozen projects i use <-- then register once and write down your login data.
11:06:34 <Rubidium> I seem to remember a patch from a week back or so about some bsd as well
11:06:37 <planetmaker> not too difficult
11:06:50 <andythenorth> wind strength could also affect aircraft
11:06:56 <andythenorth> a byte won't do it
11:07:01 <Terkhen> there are password management programs too
11:07:01 <andythenorth> it needs to be a vector
11:07:16 <andythenorth> unless we stick to a prevailing wind direction
11:07:22 <Terkhen> andythenorth: taking wind into account sounds overcomplicated
11:07:22 *** ChanServ sets mode: +v tokai
11:07:26 * andythenorth plans hot air balloons
11:07:44 <planetmaker> andythenorth, prevailing wind direction sounds quite acceptable
11:07:50 <planetmaker> the sun doesn't move either
11:07:50 <andythenorth> Terkhen: I think it would add an interesting direction to sailing ships
11:08:02 <andythenorth> 'becalmed' would be a new alternative to breakdowns :P
11:08:11 <fonsinchen> TrueBrain, could you build another version of cargodist on the compile farm, please?
11:08:17 <andythenorth> also, should ships be able to sink? Or is that just tiresome?
11:08:40 <ggergely> Rubidium: diffrent patch
11:09:00 <Rubidium> ggergely: might be, but isn't the effect the same?
11:09:07 <Rubidium> or are there multiple netbsds?
11:09:08 <ggergely> only os_abstraction.h is similiar, but define _GNU_SOURCE is a bad idea
11:09:41 <ggergely> and i made it for stable openttd on stable netbsd.
11:09:49 <ggergely> the other author probably not
11:11:38 <Terkhen> andythenorth: I think that would be annoying
11:11:51 <planetmaker> ggergely, patches are better made against trunk
11:11:54 <ggergely> and the config.lib magic is only a workaround for laziness in configure parametering
11:12:29 <ggergely> planetmaker: packags are better made of stable versions...
11:13:40 <Rubidium> ggergely: packages maybe, but making sure the next stable isn't broken works by making sure the development versions aren't broken
11:14:17 <ggergely> Rubidium: but that is a work of upstream devels, not packagers.
11:14:45 <ggergely> actually upstream should be happy by packagers doing portability fixes for them.
11:14:46 <Rubidium> ggergely: we can't test all platforms available on the world
11:14:47 <planetmaker> ggergely, then you'll remain unlucky with getting it fixed
11:15:40 <planetmaker> and there are a lot of package maintainers here who happily see a thing rather decently fixed in trunk than fixing it for one release only and then ever and ever again
11:15:40 <Rubidium> ggergely: we are happy packagers make portability fixes, but for both sides it would be better if the checks could be made before the next major release
11:16:10 <Rubidium> that way you don't have to make patches and use those for one version just to drop them for the next version again because we applied them
11:17:00 <Rubidium> and we don't have to go through backporting fixes to the stable branch (as the stable branch wouldn't have the portability issues if it were fixed before the branch)
11:18:29 <Rubidium> now, I know some packagers can be very busy and not have much time, but two similar patches in such a short period of time makes me wonder what 'causes' that
11:19:07 <ggergely> Rubidium: still, a ~6 line long patch that makes the package work, and is as simple as mine is, surely can be applied to trunk easily, as one can see by his own eye what it did (checks for netbsd version, to see if strndup is available, and similiar stuff)
11:19:38 <fonsinchen> Rubidium, I just learned that you can trigger the compile farm, too. Could you do that for cargodist?
11:19:40 <ggergely> and the patch you linked (that the bugzilla didn't find for a keword search of netbsd for me) will break stuff instead of fix
11:20:36 <ggergely> defining _GNU_SOURCE is a bad idea, where it is not defined by libc
11:21:01 <ggergely> that could break feature test macros
11:22:19 <Rubidium> ggergely: bugzilla doesn't show closed reports and so doesn't our bugtracker. If you would've searched for closed tasks you would've found it
11:22:36 <Rubidium> fonsinchen: I can, but not from here (don't have the ssh key to log in)
11:23:18 <Rubidium> hmm, netbsd still has 0.7.2?
11:24:16 <ggergely> Rubidium: yes, i'm working on updating that
11:24:18 <planetmaker> Rubidium, could you then trigger the CF when it is convenient for you?
11:24:44 <Rubidium> planetmaker: if I don't forget it (same holds for ggergely's pastebinned patch)
11:24:59 <planetmaker> :-) the usual conditions, sure :-)
11:26:22 <ggergely> Rubidium: compare this with the one you showed me, you will see the similiarities, and that your code is basically correct, you simply could not follow the extension of our libraries. but i can't iamgine how the guy with the other patch could complie the code after messing up with his patch
11:26:50 <Rubidium> heh, netbsd has had the string patch for 1 year + 1 week already (well, only with 500000 instead of 400000) and different order
11:27:12 <ggergely> it has it since 400000 according to the manual
11:27:30 <ggergely> HISTORY The strdup() function first appeared in 4.4BSD. The strndup() function was added in NetBSD 4.0.
11:27:46 <ggergely> sure, but ahoka also messed up that patch
11:28:37 <ggergely> watch the code sharply: it will not define strdup on, say a freebsd machine, but it would be needed
11:29:03 <Eddi|zuHause> <andythenorth> a byte won't do it. it needs to be a vector <-- if you use 2 bits for direction, you still have 6 bits for strength. or 3/5...
11:29:03 <ggergely> as it is needed on !gnu and !new-netbsd
11:29:45 <ggergely> or i got completely confused about that part
11:30:05 <Rubidium> the freebsd debian package compiles
11:31:04 <ggergely> oh, i didn't mean that there was a problem. merely that the expression in ahoka's patch would not define strndup at some place (freebsd was just a guess) where t might be needed
11:31:47 <ggergely> but now i'm totally confused about that
11:32:09 <ggergely> if there should be a || or &&
11:35:51 <ggergely> yes, i missed it. there should be a &&
11:36:42 *** ChanServ sets mode: +v tokai
11:36:47 <ggergely> but the negations are necessary to enter the block on a !gnu && !netbsd os, so altough ahoke missed, i also did.
11:38:13 <ggergely> Rubidium: i will make a bugreport
11:41:09 *** Chruker has joined #openttd
11:41:46 <Rubidium> if you do, make the type "bug" and not a "patch"
11:42:24 <ggergely> Rubidium: i will note that imo the bug you linked me should be rolled back...
11:48:41 *** Coco-Banana-Man has joined #openttd
11:52:42 <fonsinchen> Could it be that the compile farm makes a copy of the cloned repository with something like "cp -r" before configuring/building?
11:53:04 <fonsinchen> Or anything else that changes the files' modification dates?
11:53:37 <fonsinchen> As that is a way to trigger the false positives with "git diff-index"
12:03:44 <TrueBrain> fonsinchen: the CF does a git clone, moves it into a certain directory, runs a bit of sanity on it, uses tar on it, CF nodes download that file, extract it, and compile it
12:04:23 <TrueBrain> tar should preserve modification time
12:04:55 <TrueBrain> moves ALWAYS perserve all information
12:05:02 <TrueBrain> else it would be a copy + delete
12:05:46 <fonsinchen> so you are sure the modification times are not touched after the cloning. Then there must be another way to trigger this.
12:06:14 <TrueBrain> nobody is ever sure of anything, but it shouldn't happen
12:06:27 <TrueBrain> there can be a bit of drift in the CF node clocks, but even that should be minimal
12:06:38 <TrueBrain> either way, git would suck ass if it shows a diff over a file if only the modiciation time changed
12:06:45 <TrueBrain> would in fact make it worthless, in my opinion
12:06:50 <fonsinchen> In general "git diff-index" seems incredibly fragile. We should use a different method of modification detection
12:07:02 <fonsinchen> "git update-index --refresh" seems better
12:07:08 <TrueBrain> yeah, lets use mercurial :)
12:07:15 <TrueBrain> works much better at many many many fronts
12:07:20 <fonsinchen> it tries to update the index and complains about files with actual differences
12:07:26 <TrueBrain> in fact ... if I ever rewrite CF, I am unsure if I add git support to it ...
12:09:46 <TrueBrain> (and I am not joking .. git is one of the worst VCSs I have seen in a while)
12:10:03 <TrueBrain> also one of the slowest
12:10:27 <Eddi|zuHause> ... i don't get along with git either...
12:10:27 <TrueBrain> it wouldn't be any surprise to me if soon you need a certificate before you can use git .. it comes close to rocket science ..
12:10:40 <TrueBrain> if I see the things we have to do at our git repos to keep them 'sane' ...
12:10:51 <TrueBrain> I mean .. why doesn't it automaticly repack?
12:10:58 <TrueBrain> why can't it, in a sane way, extract subsets of a pack?
12:11:01 <TrueBrain> fonsinchen: hell no
12:11:07 <fonsinchen> but it doesn't repack aggressive
12:11:13 <TrueBrain> your git repos for example, contains at least 50 packs
12:11:17 <fonsinchen> as that takes a hell lot of RAM
12:11:17 <Eddi|zuHause> once i asked people where "short" introductions to git are, and they told me "to learn the internal structures first"
12:11:29 <TrueBrain> trying git on Windows is a hell
12:11:40 <fonsinchen> yes, and the server it's cannot repack it.
12:11:41 <Eddi|zuHause> ... i need a "scheibenwischer" smilie sometimes...
12:11:44 <TrueBrain> git often 'breaks' without you understnading why, or why it is bitching
12:11:45 <fonsinchen> It has too little ram
12:12:17 <TrueBrain> and my personal favorite: all VCSes use A to do something, and git uses BCD to do it
12:12:24 <TrueBrain> the naming scheme is absolete fucked up
12:12:40 <TrueBrain> like: ha! WE KNOW BETTER! WE KNOW MORE SANE NAMES!
12:12:58 <TrueBrain> so lets all just please drop git
12:13:01 <TrueBrain> and start using mercurial
12:13:16 <fonsinchen> I didn't write git, you know. I also didn't try mercurial. But so far I cannot complain about git.
12:13:38 <TrueBrain> I never suggested you wrote git, did I?
12:13:44 <TrueBrain> In that case I would flame you personally
12:13:52 <TrueBrain> and really, do try mercurial
12:14:14 <TrueBrain> I am very sure your M problem will be gone ;)
12:14:36 <fonsinchen> Actually IS obviously had the same problem
12:14:46 <fonsinchen> and as far as I can see they are using mercurial.
12:14:57 <fonsinchen> but probably it only looks similar.
12:15:22 <TrueBrain> the things IS did, was not to fix the M
12:17:49 <planetmaker> IS did explicitly set a version
12:18:15 <fonsinchen> How well would mercurial manage those 20 branches I have in my repository? Maybe I should really try, but what I have read is that git is the best option if you have lots of branches and create/destroy them on a regular base.
12:18:33 <TrueBrain> I like Mercurial Queue system
12:18:46 <TrueBrain> not sure how well it works for 20 patch-sets
12:19:42 <fonsinchen> Well, I have to leave. Bye
12:21:32 <Rubidium> maybe there's a timezone issue?
12:22:01 <Rubidium> i.e. do all compiles have problems, or only the compiles on a few platforms?
12:24:54 <planetmaker> fonsinchen, in any case hg does support branches, both named and unnamed
12:29:45 <Eddi|zuHause> hm... windows shares are a mystery to me...
12:29:53 <Eddi|zuHause> i'm very frustrated right now...
12:30:28 <Eddi|zuHause> i set the windows share so that "everybody" has "full access", but smb tells me to enter a password, and denies access
12:31:10 <Eddi|zuHause> i have no idea what that means...
12:31:28 <TrueBrain> Windows Vista and higher require a higher level of security (by default) for authentication and authorization
12:31:47 <TrueBrain> this new NTLM causes Windows computer not to be able to see samba shares, and visa versa
12:32:26 <Eddi|zuHause> i see the shares on the windows computer, but i can only access some of them...
12:32:38 <Eddi|zuHause> and i don't know the difference...
12:33:01 <Eddi|zuHause> and i don't find an "allow guest access" button...
12:33:53 <Eddi|zuHause> i want an "I DON'T FUCKING CARE" button... or at least an explanation what this stuff does... but windows does apparently not provide any help, or descriptive interface...
12:34:34 <TrueBrain> I had to install Windows 2008 server last month (poor me) ... now that is a hell o undescriptive texts and stuff
12:34:57 <TrueBrain> for example, if you disable 'last documents' in the Start Menu, it also dissapears from Microsoft Office (but not from Open Office)
12:35:07 <TrueBrain> they could at least have made a remark about that :p
12:35:11 <TrueBrain> but he .. it is microsoft
12:36:04 <Eddi|zuHause> i completely don't understand it... everything used to be so easy...
12:36:17 <Eddi|zuHause> i had shared this folder before, but now moved it to another disk
12:36:26 <Eddi|zuHause> so i had to "reshare" it...
12:36:32 <Eddi|zuHause> and now it denies access...
12:37:00 <Eddi|zuHause> i'm getting too old for this shit...
12:42:20 <dihedral> Eddi|zuHause: "frueher war die zukunft auch besser" :-P
12:46:56 <Eddi|zuHause> it's totally ununderstandable... there is no visible difference in the settings between the shares i can acces and the ones i cannot access...
13:04:08 <CIA-6> OpenTTD: glx * r19846 /trunk/src/lang/ (45 files in 2 dirs): -Fix (r19839): STR_NEWGRF_SETTINGS_SELECT_PRESET != STR_NEWGRF_FILTER_TITLE and do it for unfinished lang files too
13:20:37 *** roboboy has joined #openttd
13:27:18 <Eddi|zuHause> why does copying over the network only have 4.6MiB/s?
13:30:06 *** JostVice has joined #openttd
13:32:54 <Rubidium> because it's 54 Mbps wireless?
13:34:02 <Eddi|zuHause> no... it's supposed to be 100Mbps
13:35:06 <Eddi|zuHause> and other network traffic is marginal
13:35:18 <__ln__> good switch or crappy switch?
13:37:32 <Eddi|zuHause> iptraf says ~8300 kbits/s, the copy dialog says 4.3 MiB/s... is there such insane amount of protocol overhead in samba?
13:38:14 <Noldo> there might be some tweaking possibilities
13:38:21 <Rubidium> with dropped packets that could very well happen
13:39:12 <Rubidium> samba over VPN gets me like 100-200 kBps, whereas ftp over the same connection (same server) gets 1100-1200 kBps
13:42:57 <TrueBrain> Eddi|zuHause: maybe it has to acknowledge every bit :p
13:43:40 *** Chillosophy has joined #openttd
13:51:25 <Belugas> hello sir andythenorth
13:55:42 <Belugas> she is quietly at home (doing some laundry, cake and bread), mister Sacro ;)
13:56:57 *** Devroush has joined #openttd
14:01:27 <TrueBrain> Belugas: what are you doing the 19th of June? Any chance you can be in a plane to Germany? :p
14:01:53 <Eddi|zuHause> (it's a saturday)
14:02:25 <Belugas> nope.. cannot be there.
14:02:37 <Belugas> i'm doing a concert in japan
14:02:47 <Belugas> we've got the Budokan stadiom reserved
14:03:19 <TrueBrain> we have a party at planetmaker's place
14:03:22 <TrueBrain> and we wanted you to be there
14:03:25 <TrueBrain> but I can see Japan has priority
14:04:49 *** fonsinchen has joined #openttd
14:15:19 * dihedral wonders if TB receives private messages ^^
14:15:56 <Belugas> fucking stupid distance
14:15:56 <Eddi|zuHause> depends on your definition of "receive" ;)
14:16:12 *** orudge_ has joined #openttd
14:17:27 <Eddi|zuHause> dihedral: a german court recently defined an email as "received" when it was caught by the spam filter and deleted.
14:19:13 <dihedral> recently is good, i thought that was at least quite some months ago
14:19:42 <Eddi|zuHause> can't be that long ago... one, maybe two, months...
14:20:41 <dihedral> that's a bummer, as, iirc, even those emails must be archived
14:23:10 <Eddi|zuHause> hm... apparently the ruling was already in July 2009...
14:23:39 <Eddi|zuHause> but it was mentioned in a news from February 2010, where i read about it
14:24:55 <Eddi|zuHause> "Das Landgericht Hamburg entschied, dass die von einer Firewall abgefangene E-Mail als "zugegangen" zu beurteilen sei und dass das Risiko, dass eine solche E-Mail verloren gegangen sei, ganz bei dem Abgemahnten läge."
14:27:41 <Rubidium> Belugas: that's only a 10 minute walk from the hotel I stayed in :)
14:27:48 <Eddi|zuHause> anyway... "last year" is still "recently", even for the internet
14:30:40 <dihedral> yes, that sounds about right
14:32:50 <peter1138> Eddi|zuHause, 24 hours is ages ago, on the Internet...
14:40:36 <Rubidium> Eddi|zuHause: so... is a rejected email after "MAIL FROM" considered received?
14:42:45 <peter1138> usually you reject after RCPT TO
14:42:54 <peter1138> (but before DATA of course)
14:43:06 <Rubidium> okay, RCPT TO then :)
14:43:33 <Rubidium> anyhow, compared to snail mail you would have received the enveloppe
14:55:49 <Eddi|zuHause> i don't know the details of email delivery
14:57:02 <peter1138> the question is, is it received even if it isn't received?
15:05:49 *** lewymati has joined #openttd
15:06:40 *** Weeknie has joined #openttd
15:12:18 <Weeknie> Could anyone help me get started on newGRF airports?
15:12:29 <Weeknie> I mean, I would like to help coding them, but where do I start so to speak?
15:12:58 <glx> IIRC newgrf airport support is still WIP
15:13:17 <Weeknie> (never heard of that one:P)
15:13:33 <Weeknie> That's why I wanna help develop:)
15:13:44 <Weeknie> But I have absolutely no idea how to start
15:16:13 <OwenS> Weeknie: I assume you're an experienced C++ coder?
15:16:41 <glx> you first need to clone Yexo's hg repo
15:17:44 <Weeknie> OwenS, no, just beginning, but I'll learn along the way, that's the idea anyway
15:17:46 <Yexo> Weeknie: have you compiled the trunk version of openttd already?
15:17:56 <Weeknie> Yes I finally got that done yesterday:P
15:18:12 <OwenS> Weeknie: Thats your first step. Your second step is learning NFO indepth. And I mean in depth.
15:18:44 <Weeknie> Erm, Yexo, do you agree that I should do that?
15:19:27 <Yexo> most (if not all) of the newgrf airports code will be relying on newgrfs, so you have to know how they work
15:19:28 <Weeknie> But tbh, I wouldn't have any idea on how to learn C++ other than just coding
15:20:07 <Yexo> the problem with newgrf airports is that you would try to learn to things at the same time, c++ and nfo
15:20:20 <Yexo> both are hard enough to learn already
15:20:42 <Weeknie> It's not like I haven't coded before
15:21:12 <glx> don't forget c++ implementation of nfo specs (that's a third thing ;) )
15:21:57 <Weeknie> But erm, well, what should I learn about NFO's then?
15:22:01 <Weeknie> I know generally how they work
15:22:06 <Weeknie> not the specific actions and such
15:22:36 <Yexo> learn about advanced varaction2, and then write a newgrf yourself that uses it
15:23:00 <Weeknie> Hmm, that might be a good idea yeah
15:23:32 <Yexo> if you want to learn to work with the storage, try an industry newgrf and play a bit with the production code
15:24:09 <Weeknie> I was especially interested in how the new airports will work
15:24:25 <Weeknie> Was hoping to implement my idea of the airport statemachine
15:25:28 <Weeknie> hah, yeah, didn't understand that before, let's go through it again and see whether I can figure out how it works
15:25:43 <Yexo> but it's not fully implemented yet, so if your airport newgrf doesn't work it might as well be a bug in the c++ code
15:26:09 <Weeknie> I think I'll just see if that all makes sense to me
15:26:18 <Weeknie> Else I'll go play around with some vehicle or industry grf's
15:26:31 <Weeknie> Thanks for the help anyway;)
15:26:34 <glx> stations are easy to test too
15:26:58 <Eddi|zuHause> one of the big design problems with airport state machines is how it could be extendable for other vehicles, like ships and road vehicles, and especially articulated road vehicles
15:27:00 <Weeknie> Do really all objects in the game have nfo's?
15:27:18 <Yexo> Eddi|zuHause: ships are pretty easy
15:27:39 <Yexo> just have to define an entrance/exit point and the rest could be done via the same staemachine callback as for aircraft
15:27:54 <Yexo> articulated road vehicles are far more tricky
15:28:15 <Eddi|zuHause> very far more, yes ;)
15:28:27 <Yexo> I have no idea how the code works that the articulated parts follow the front vehicle (nor have I tried to understand it yet)
15:29:31 <Weeknie> Well, let's go reading
15:30:10 <Eddi|zuHause> well, i once had an idea how it could be done: each vehicle gets a shift-register of the positions it went through, and on movement, the last entry gets shifted into the next vehicle, and that vehicle gets forced on that position
15:30:27 *** fonsinchen has joined #openttd
15:30:28 <Eddi|zuHause> you'd need 8 registers for a length 8 vehicle, and less for shortened vehicles
15:31:50 <Eddi|zuHause> but you need some special magic for things like reserving/unreserving of certain states
15:32:01 <Yexo> is that also going to work if you have a small truck with a few very long trailers?
15:32:39 <Yexo> Eddi|zuHause: (un)reserving states should be done by the newgrf
15:33:10 <Weeknie> This periodic processing loop, how many times is it run? (as in how many ticks between loops)
15:33:35 <Eddi|zuHause> Yexo: yes, but with articulated vehicles you need to separate reserving (on entrance of the first vehicle) from unreserving (leaving of the last vehicle)
15:34:01 <Weeknie> ERm, Yexo, I think you're misunderstanding me then
15:34:19 <Weeknie> Im looking at action 0 for airport tiles
15:34:19 <Yexo> Eddi|zuHause: stlil can be done by the newgrf, "reversing" = setting a bit in the persistant storage of the station
15:34:28 <Weeknie> Then under 11b (not sure what that is though)
15:34:56 <Yexo> it's run every 256 ticks
15:35:03 <Yexo> each tick some tiles are processed
15:35:28 <Weeknie> Sorry, the b was between brackets
15:35:29 <Yexo> 11h/0x11, but it's a byte value :)
15:35:44 <Weeknie> Why is there then also a value which executes the statement every 250 ticks?
15:36:10 <Yexo> that is for all tiles of the airport at the same tile
15:36:17 <Yexo> the tile processing loop does a few tiles every tick
15:36:38 <glx> same for stations and industries IIRC
15:36:47 <Weeknie> So all of them get handled a few at a time, and all simultaniously every 250 ticks
15:37:23 <Eddi|zuHause> Weeknie: you can observe the effects of the tile loop best if you watch some farm fields on fast forward. or grass growth, when you cleared a large area
15:37:28 <Yexo> start openttd, clear a large area of ground and see in fastforward the grass regrow
15:37:34 <Yexo> that is done in the tile processing loop
15:37:48 <Weeknie> I've noticed that before
15:38:06 <Eddi|zuHause> the tiles are processed in a fixed pattern
15:38:37 <Eddi|zuHause> step by step, so the CPU is not overloaded
16:13:37 <_Ben_> Anybody around who has any idea of how to get the extra coastal sprites appearing in game?
16:14:15 <_Ben_> For temperate do they go in ogfxe_extra as 1863-1870?
16:30:03 *** NukeBuster has joined #openttd
16:34:23 <_Ben_> Ammler: the first link is instructions how to run the 32bpp EZ branch, or am I missing something
16:34:25 *** rhaeder has joined #openttd
16:34:28 <Ammler> he should split in files
16:34:44 <Ammler> _Ben_: no, it is all about the extra grf
16:35:38 <Ammler> >1800 seems ok, but how you find the exact sprite numbers is quite hard.
16:35:41 <_Ben_> oh, is that required to display sprites?
16:36:12 <Ammler> yes, if you don't want to change the number with every new ogfx release
16:37:49 <_Ben_> hmm, I found the numbers from a .tar which maquinista had made, I didn't find them myself. I wonder if their not working then becuase the extra-sprite numbers have been changed..?
16:42:22 <Ammler> yes, they change on every grf change
16:42:32 <Ammler> we told you that around 1000 times
16:42:48 *** mib_qgxzpw has joined #openttd
16:42:52 <mib_qgxzpw> 4on4 server on nuke high
16:42:55 <_Ben_> yeah...well..not quite that often, but that's meaningless to someone who doesn't know how/if when a grf change is made
16:42:59 <Ammler> that is why you should use that special 32bpp extra newgrf
16:43:15 <mib_qgxzpw> 4on4 server on nuke high
16:43:30 *** Grelouk has joined #openttd
16:43:53 *** mib_qgxzpw has left #openttd
16:44:12 <_Ben_> I asumed the file on the repe would have been updated...or is that irrelevent? it doesn't state the grf is required, or include the grf in the pack
16:44:18 *** |Jeroen| has joined #openttd
16:44:29 <_Ben_> meh, I have that grf and it doesn't seem to have worked
16:44:43 <Ammler> you need to load that grf
16:45:21 <Ammler> dunno, how it is done with ez patch, but with trunk you need to load it with newgrf gui
16:48:25 <_Ben_> why is that grf included with all the extra sprites? seems random why half of them are bundled
16:48:42 <Ammler> you need to load it once
16:49:00 <Ammler> it doesn't need to be bundled with every tar
16:49:07 <Ammler> but it might also not hurt
16:49:50 <_Ben_> well that's what confused me because I didn't require any of the sprites, so haven't ever downloaded that file.
16:50:22 <_Ben_> saying that, I'm still also confused why the sprites have the numbers they do inside that pack, even if the grf changes that so they work
16:50:23 <yorick> "Rollercoaster Tycoon movie"
16:50:30 <Weeknie> Rollercoaster Tycoon!:D
16:51:15 <Ammler> well, it depends where on the grf the change happen, if the sprite change is almost at the end, it wouldn't affect that much
16:51:50 <yorick> "with plans to make a "live-action/CGI hybrid.""
16:51:55 <Ammler> last change for example was gui change, that is one of the top grfs
16:52:07 <Ammler> so it affects almost every sprite :-)
16:52:54 <_Ben_> hmm this is baffling me. Why do half the coastal sprites that exist in trg1r need to be in this set?
16:53:15 <Ammler> they don't, base set is special
16:53:41 <Ammler> but the extra newgrf isn't a baseset, so you might need it
16:54:16 <_Ben_> hmm 1808_z0.png seems exactly the same, and it loads instead of the sprite I have in trg1r, so it's called up for the same reason
16:54:59 <Ammler> yeah, sorry, the 32bpp extra grf is a newgrf, that is why you need to copy those
16:55:51 <Ammler> maybe GT should define a baseset GRFID, but not sure about that
16:57:39 <Ammler> AFAIK is that the only special case with base set extra grf
16:58:24 <_Ben_> errrr....all this termonology
16:59:18 <_Ben_> one sec, ...the sprites all disapeared
17:01:19 <Ammler> GT does also directly include 32bpp pngs in that newgrf, btw.
17:04:19 <_Ben_> ok I'm going mad. I can't now get the sprites in that tar to appear. I have the newgrf and the .tar as they were
17:05:25 <_Ben_> I have a lot of folders, any idea which ones are still needed? ogfx1_base ogfxe_extra openttdw trg1r trgcr and trghr
17:07:14 *** Lakie` is now known as Lakie
17:08:48 <_Ben_> right, redid everything and it works again. Still can't understand why some of the 32bpp sprites from trg1r have been replaced with the ones in the 32bpp extra set. Can you explain preferably with minimal in-termonology why there are 2 versions of the same sprite?
17:09:30 <glx> extra is a newgrf, so it can replace some original sprites
17:10:04 <_Ben_> whats the need in that case of the coastal sprites?
17:10:11 <Weeknie> Can NML2NFO also pack NFO's and GCX's to GRF's?
17:10:37 <glx> 0D,...Coast Tile graphics,...16 (18),...2.5 beta 5, OpenTTD r7325 (OpenTTD r11726)
17:11:40 <Weeknie> Which option do you need in that case?
17:11:47 <Weeknie> I checked -h but it's not really obvious from there
17:12:39 *** frosch123 has joined #openttd
17:13:14 <_Ben_> ok, some read. What I'm asking though is why sprites have to be cloned, put in another folder, and then have a newgrf to appear exactle the same. Obviously the bulk of the extra graphics didn't exsist before, but half these coastal sprites were, and still are in trg1r
17:13:33 <yorick> Weeknie: it does it by default
17:14:18 <Weeknie> Oh wait, that's right, the gcx's are named in the nfo
17:15:35 *** Alberth has joined #openttd
17:17:26 <Ammler> nml can't read nfo, afaik
17:17:41 <Ammler> you need grfcodec for that
17:24:03 <planetmaker> <Ammler> maybe GT should define a baseset GRFID, but not sure about that <-- very bad idea
17:24:26 <planetmaker> it should only be defined by base sets. Only be the extra newgrf which comes with a base set and is defined in the base set description file
17:25:42 *** fonsinchen has joined #openttd
17:26:05 <planetmaker> Weeknie, you might get the file extension correct ;-)
17:26:39 <planetmaker> but actually you're happy, you cannot only use pcx files in NML, you can also use png files as source
17:26:59 <Weeknie> I'm not gonna do any designing
17:27:17 <Weeknie> I'm just going to take that OGX+ set and write the whole NFO code myself to get used to i
17:27:32 <Ammler> planetmaker: that grf is baseset extra grf
17:27:54 <planetmaker> why then bother with nml?
17:28:11 <planetmaker> Ammler, a base set extra newgrf needs definition in a base set obg file
17:28:15 <Weeknie> Because I don't have grfcoder here
17:28:28 <Weeknie> Since you said nml could do it too:P
17:28:30 <planetmaker> so... you write nml, not nfo? I don't get it
17:28:35 <Ammler> check development page on openttd.org
17:29:01 <Weeknie> Let me ask you this first
17:29:05 <fonsinchen> TrueBrain, Rubidium: Could one of you please build another version of cargodist on the CF?
17:29:16 <Weeknie> Can NML2NFO also do the same thing grfcoded does?
17:29:29 <Weeknie> (remove the also, that doesn't belong there in that sentence)
17:29:38 <planetmaker> it can't compile nfo. It can only compile nml files
17:29:58 <planetmaker> it's like: can a c compiler do what a fortran compiler can do
17:29:58 <Weeknie> Sigh, thanks a lot Yorick:P
17:30:05 <Weeknie> I don't care about the decoding
17:30:12 <Weeknie> Got the OGX+ source;)
17:30:26 <planetmaker> both compilers have different input, one requires c files, the other fortran files.
17:30:43 <planetmaker> same with nml / grfcodec: nml requires nml files, grfcodec nfo files :-)
17:30:49 <Weeknie> Well, Yorick said it could do NFO's + PCX:P
17:30:55 <planetmaker> ogfx+ is in NML :-)
17:31:22 <Weeknie> Well that's even better, no hex code to spy on
17:31:48 <Weeknie> Unless you're planning an nml implementation for the newgrf airports:P
17:32:15 <glx> not until it's finished I guess :)
17:32:50 <planetmaker> Weeknie, nml doesn't change the way newgrfs work. It's just another programming language
17:32:58 <planetmaker> You still need to jump through all the concepts
17:33:41 <Weeknie> So I'll just go do NFO stuff and get grfcodec after all
17:34:09 <planetmaker> you got IMHO some fundamental mis-understanding there on what NML / NFO are :-)
17:34:16 <Rubidium> fonsinchen: (TrueBrain) started it; it'll probably be stalled by the normal nightly though
17:34:47 <TrueBrain> I didn't do such thing :(
17:34:53 <planetmaker> they are both a programming language
17:35:05 *** nighthawk_c_m has joined #openttd
17:35:26 <planetmaker> like a compiler for each programming language produce the same binary code so that a computer can execute it, both these languages, NFO and NML do so with grfs
17:35:35 <Weeknie> planetmaker, I do understand it
17:35:54 <Weeknie> Here's what I wanna do
17:36:16 <Weeknie> Or well, at first, I wanted to implement an airport the way I had thought up, as you read on the forums
17:36:41 <Weeknie> Well that's impossible, because newgrf airports aren't fully developed yet
17:36:46 <Weeknie> So then I thought, let's help them develop it
17:37:08 <nighthawk_c_m> If I have a working cargodist route - goods from a factory to several statoions, and the route is shut down inbetween for whatever reason, suddenly the factory only produces goods for one explicit station
17:37:23 <planetmaker> Weeknie, that won't save you then from understanding the specs, right
17:37:44 <Weeknie> So that's why I've got to go learn them
17:37:59 <fonsinchen> oh, you didn't ...
17:38:07 <Weeknie> Yes, that's what I meant
17:38:13 <planetmaker> :-) you don't need to understand every syntax. But the concept.
17:38:29 <Weeknie> What exactly would you mean by concept then?
17:38:49 <planetmaker> how variables work, how actions0...F work and what they're capable of
17:39:00 <Weeknie> Right, so that's what I was about to do;)
17:39:04 <planetmaker> but you don't need to write your airport then in NFO
17:39:17 <Weeknie> Oh no, not going for that specifically
17:39:29 <Weeknie> Just going to write my own bus or something, something simple
17:39:34 <Weeknie> To get the hang of all the NFO stuff
17:43:21 <planetmaker> simple vehicles are easy :-) Like the trams in ogfxplus
17:43:44 <planetmaker> just graphics and some stats attached to them
17:44:20 <planetmaker> The fun begins when you start to change the behaviour / looks / ... of them depending upon date and other things :-)
17:44:38 <planetmaker> or adding refit options to them like HEQS does
17:44:45 <planetmaker> for the cargo trams
17:45:09 *** Chillosophy^ has joined #openttd
17:45:23 <Weeknie> Lol, that's what I wanted to do
17:45:28 <Weeknie> Start with something easy
17:45:32 <Weeknie> And then expand upon that
17:45:37 <Weeknie> But another little question
17:45:42 <Weeknie> When and where do trams get introduced?
17:45:48 <Weeknie> Never seen em enabled in any game I played
17:46:23 <CIA-6> OpenTTD: translators * r19847 /trunk/src/lang/ (14 files): (log message trimmed)
17:46:23 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
17:46:23 <CIA-6> OpenTTD: catalan - 5 changes by arnau
17:46:23 <CIA-6> OpenTTD: croatian - 4 changes by VoyagerOne
17:46:23 <CIA-6> OpenTTD: dutch - 66 changes by Hyronymus, habell
17:46:25 <CIA-6> OpenTTD: finnish - 4 changes by jpx_
17:46:25 <CIA-6> OpenTTD: french - 5 changes by glx
17:46:49 <Alberth> you need to load a tram newgrf I think
17:49:29 *** CrazyTB has joined #openttd
17:50:09 <Rubidium> damn... shouldn't have looked at the Dutch translation diff. It already gets on my nerves again
17:50:47 <Rubidium> TrueBrain: on vacation in Brazil? :)
17:51:16 <glx> Rubidium: stupid translations ?
17:51:50 <Rubidium> glx: the first string I look at having spelling errors
17:52:10 <Alberth> fire the translator :p
17:52:12 *** CrazyTB has joined #openttd
17:52:22 <Rubidium> and to be honest my spelling isn't that good, just the translation's spelling is worse
17:53:09 *** CrazyTB has joined #openttd
17:53:42 <TrueBrain> Rubidium: nothing new there
17:53:46 <TrueBrain> and why would I be in Brazil?
17:54:01 <Rubidium> TrueBrain: your alter-ego CrazyTB
17:55:27 <Weeknie> Lol Rubidium, I could take a look if you want:P
17:55:59 <TrueBrain> I once had the plan to walk over every string
17:56:03 <TrueBrain> sadly, WT3 tracks that poorly
17:56:29 * peter1138 walks over TrueBrain
17:56:40 <TrueBrain> the general best tip is to never use Dutch as language in any application
17:56:41 <Weeknie> And Alberth, my standard openTTD is already saying something like "streettrain" or something like that
17:56:50 <Weeknie> So it's supposed to already be there
17:57:15 <Rubidium> it's probably inconsistent too, but that requires a more thorough review and possibly some sort of "translation table" for certain terms
17:57:22 <Weeknie> Lol, yorick, that's the idea:P
17:57:47 <_Ben_> ok, last question I promise...if I can do this I'll disapear and go hang out in photoshop some more. Is it possible in the EZ 32bpp build to display the coast sprites that sit in the multiple steep gradient V-valley tiles?
17:59:05 <Rubidium> e.g. screenshot being 'translated' to 'screenshot' and 'schermprint'
17:59:17 <TrueBrain> Rubidium: we once already started with that
17:59:22 <TrueBrain> but the lack of support for that in WT3 makes it annoying
17:59:53 <Rubidium> then add support for that in WT3(.1) :)
18:00:48 <TrueBrain> just no time for WT3.1 :p
18:01:37 <Rubidium> ... 'tramweg' vs 'tramrails'
18:01:54 <CrazyTB> hey, people... I've just installed OpenTTD 1.0.1 on Gentoo/Linux and the jukebox just keeps showing all songs very fast.
18:01:57 <Weeknie> erm, Rubidium, what exactly do you mean?
18:02:06 <Weeknie> Did someone really translate as tramweg...?
18:02:18 <CrazyTB> I've checked the FAQ, and I know the songs are at the correct directory, and it is not a permission issue.
18:02:40 <yorick> CrazyTB: I had that once :P
18:02:50 <yorick> forgot how I fixed it though
18:03:06 <glx> CrazyTB: installed timidity?
18:03:15 *** Sionide has joined #openttd
18:03:19 <Rubidium> Weeknie: why would I mention it if it isn't the case?
18:03:29 <Weeknie> Wasn't sure lol, sorry
18:03:34 <Weeknie> Ayway, I agree with you:P
18:03:45 <CrazyTB> yeah, it's installed...
18:04:00 <Rubidium> TrueBrain: the compile farm's priority system seems to do its job :)
18:04:34 <CrazyTB> Running "timidity -iA -Os" does not help either
18:04:37 <TrueBrain> of course it does :)
18:04:41 <Rubidium> CrazyTB: and timdity <one-of-the-music-files> helps?
18:04:49 <TrueBrain> it is a named-sorted priority system
18:04:57 <TrueBrain> and the priority value is the first char of the dir :p
18:05:36 <CrazyTB> yeah, timidity by command-line can play the file
18:05:50 <Rubidium> can timidity run it while OpenTTD is running?
18:06:43 <CrazyTB> Rubidium: yes, it can
18:07:43 <Terkhen> I have the same issue on arch, still not had time to check why that happens :P
18:08:01 <Terkhen> I was assuming a wrong installation of timidity on my part
18:08:21 <CrazyTB> hmmm... Maybe it is a build-option issue... let me check
18:09:02 * andythenorth wonders if he mentioned a great idea about wind strength :P
18:09:40 <Weeknie> What did andythenorth mention then?
18:11:01 <CrazyTB> okay, I *think* I found the problem
18:11:12 <CrazyTB> It was built with --with-midi=/usr/bin/aplaymidi
18:11:28 <CrazyTB> I should probably build it with timidity instead of aplaymidi
18:12:25 <Rubidium> yeah, or install aplaymidi
18:12:38 <Rubidium> well, it fails for some reason
18:12:40 <CrazyTB> but it can't play midi files on my system
18:13:02 <CrazyTB> well, gotta eat something, I'll test soon
18:13:18 <Rubidium> well, file a bug report about the openttd package at gentoo saying aplaymidi fails to play the midis and timidity (the upstream default) does work
18:25:52 *** last_evolution has joined #openttd
18:26:08 <Wizzleby> or, you could just tell me right here and now (which you did)
18:26:27 <Wizzleby> idk why aplaymidi was the default, but it can be changed
18:27:16 <Wizzleby> so. timidity, or libtimidity?
18:29:07 <Wizzleby> Rubidium, CrazyTB: FWIW, since I picked up that package, I've been trying to get it to be more sensible about its defaults
18:32:36 *** Beklugas has joined #openttd
18:33:27 <Rubidium> Wizzleby: you can't do much about the state of the package besides convincing bones (at the moment)
18:37:29 *** ajmiles has joined #openttd
18:37:30 *** ajmiles2 has joined #openttd
18:37:43 <Wizzleby> Rubidium: although I am not (yet) a gentoo developer, I am the one who brought openttd-1.0.0 to gentoo, I have been maintaining ebuilds in overlay (gamerlay overlay, which is globally available to gentoo users through layman) which have eventually been moved to tree by the games team. If I fix it in overlay, it is available immediately to anyone using the overlay
18:38:12 *** ajmiles has joined #openttd
18:38:55 <Wizzleby> and if CrazyTB does file a bug, I also have impetus to submit my modifications to the ebuild as a fix
18:39:06 <Wizzleby> hm, I mean, impetus for said fix to be accepted
18:39:15 <CrazyTB> Wizzleby: I think that aplaymidi should be choosen IF timidity useflag is not set
18:39:38 <CrazyTB> else (if use timidy), then the default should be kept (which is to use timidity)
18:40:41 <Wizzleby> CrazyTB: yeah, currently it sets --with-midi=/usr/bin/aplaymidi if use alsa is enabled. But if libtimidity is present, it automagically links to it
18:41:44 <Wizzleby> a lot of stuff in there is apparently quite old, as the openttd ebuild has not had an actual maintainer (aside from the games herd) for a few years, due to the previous maintainers retiring
18:41:56 <CrazyTB> Wizzleby: it does? ldd shows no timidity in openttd.
18:43:39 <CrazyTB> well... I don't have anymore a machine on which aplaymidi works. Thus, I can't test if --with-midi=/usr/bin/aplaymidi really works.
18:43:40 <Rubidium> then you don't have libtimidity (a separate package) installed
18:44:12 <CrazyTB> Rubidium: yeah, I don't have. And even if I had, it should have not been an "automatic dependency"
18:45:08 <Rubidium> that's up to the packager
18:46:00 <peter1138> you could learn to set up a synth, heh
18:46:04 <Wizzleby> yeah, generally, we don't want automatic dependencies, we want them togglable. choice
18:46:10 <Wizzleby> FWIW, aplaymidi never worked for me either
18:46:11 <Rubidium> or do you want ./configure --enable-sdl --enable-zlib --enable-png ...?
18:46:26 <Rubidium> Wizzleby: so, --without-libtimidity
18:47:14 <Wizzleby> Rubidium: yeah, that's what's going to be pushed to the gamerlay overlay soon as I get done cleaning up the ebuild (working on it now). alsa should not force aplaymidi, that's just bad form
18:47:18 <CrazyTB> Rubidium: But SDL or so are already listed at DEPEND. libtimidity, on the other hand, wasn't.
18:47:49 <Rubidium> CrazyTB: but that's Gentoo's package; not something "we" (openttd developers) have control over
18:49:22 <Wizzleby> Rubidium: you probably have more influence over it these days than before I picked it up.. it really had no-one with a focus to giving the package the love it needs before that
18:50:08 <Wizzleby> and here is where I come first with questions about how you guys build it, and what are your default/preferred options
18:53:05 <Wizzleby> once I complete my quizzes, and move through the rest of the recruitment process, I intend to request maintainership of the ebuilds for openttd, the media sets for it, and their few deps, and also to join the games herd.
18:57:33 * Wizzleby wonders why the original maintainers put SDL support under the alsa useflag
18:58:10 *** George is now known as Guest425
18:58:16 <Rubidium> Wizzleby: probably because nobody with a proper understanding of everything did take a look at it
18:58:35 <CrazyTB> it's under -dedicated
18:58:52 <Wizzleby> CrazyTB: under both -dedicated and alsa ;)
18:59:04 <Wizzleby> its an old, messy ebuild for sure
18:59:18 <CrazyTB> Are you sure? Are you looking at the same ebuild as me?
18:59:51 <CrazyTB> Care to pastebin the version you're looking at?
19:01:33 <Wizzleby> look down at the else past the if use dedicated part
19:01:40 <CrazyTB> line 58 is independent of 59
19:02:26 <CrazyTB> even if alsa is not set, the line 59 will be run.
19:03:37 <Rubidium> yay for (sh?) trickery
19:04:00 <CrazyTB> Rubidium: a very common trick, by the way
19:04:25 <Rubidium> maybe, but it makes the code less readable
19:04:49 <CrazyTB> sometimes yes, sometimes no
19:05:14 <Wizzleby> yes, this ebuild would totally get me chewed out if I pushed it to the kde overlay (lets just pretend it was a KDE app) cause it doesn't meet formatting standards
19:06:43 <TrueBrain> poor english in the openmsx notice
19:07:22 <TrueBrain> (thought it would be a good time to bring that up :p)
19:07:32 <Wizzleby> TrueBrain: thanks for the heads up :)
19:07:49 <TrueBrain> in general, the entries are poor english, and hard to read
19:07:58 <TrueBrain> "alsa not in USE so music will not be played during the game." <- had to read it 4 times :p
19:08:18 <TrueBrain> 'alsa' is not in USE; therefore music will not be played during the game." or something :p
19:08:37 <TrueBrain> but the missing verb in the first part, and a missing seperate between the two parts make it hard to read
19:08:49 <TrueBrain> [robot voice] ALSA NOT IN USE [/robot voice]
19:09:23 <Rubidium> even then, if you compile timidity with e.g. oss support and the kernel supports oss, you'll possibly have music
19:09:31 <Rubidium> as such the statement can be incorrect
19:10:27 <CrazyTB> maybe that statement should be deleted entirely
19:10:31 <Rubidium> likewise "File names are case sensitive so make sure they are" is incorrect; for both the Windows and DOS version both fully uppercase and fully lowercase is supported
19:10:58 <TrueBrain> Rubidium: still is case sensitive, but two allowed forms ;)
19:11:27 <TrueBrain> and well, now we are this far:
19:11:28 <CrazyTB> I've just recompiled openttd without that --with-midi flag. Now it calls /usr/bin/timidity, and the music is played correctly.
19:11:28 <TrueBrain> ewarn "Warning: The init script will kill all running openttd"
19:11:30 <TrueBrain> ewarn "processes when run, including any running client sessions!"
19:11:31 <TrueBrain> processes vs sessions
19:11:42 <TrueBrain> 'when run' .. might be mistaken, shouldn't that be 'when ran'?
19:11:55 <TrueBrain> but better: when executed, or triggered
19:12:05 <Rubidium> also saving ancient savegames isn't disabled, it just fails
19:12:08 <CrazyTB> (but it's weird that timidity process shows up as extmidi in process list)
19:12:28 <Rubidium> (disabled implies you don't see old savegames or something)
19:12:38 <TrueBrain> Wizzleby: and yes, those things always annoyed me, but after sending a patch to the maintainer of that time for a 4th time, I gave up on Gentoo :p
19:12:55 <TrueBrain> Rubidium: maybe you can rewrite the whole text? :)
19:13:19 <Rubidium> also opensfx isn't needed; only opengfx or trg*.grf
19:13:26 <TrueBrain> you must either install games-misc/opengfx as well as games-misc/opensfx or copy the following 6 files (.)) <- also crappy english
19:13:37 <TrueBrain> either (..) as well as (..) or (..)
19:13:43 <TrueBrain> bad construction :)
19:14:44 <TrueBrain> now something positive: I like Gentoo uses binaries.openttd.org as source :)
19:15:07 <Rubidium> TrueBrain: there isn't much else to use (besides mirrors directly ofcourse)
19:15:15 <TrueBrain> they have their own mirror too
19:15:18 <TrueBrain> so that is why I say it :)
19:15:55 <Rubidium> maybe that can't work with gamerlay?
19:16:22 <TrueBrain> it can; the maintainer can pick either one; but it is nice they hit our mirrors, as then we can track downloads :)
19:16:32 <TrueBrain> they also use sourceforge mirrors where possible, I like that too :)
19:16:44 <CrazyTB> TrueBrain: instead of sending a patch to the maintainer, have you tried to post the improvements at the bugzilla?
19:17:15 <TrueBrain> gave up on that too
19:17:21 <TrueBrain> been promised stuff a few too many times :)
19:17:49 <TrueBrain> Gentoo Games herd does not really have any record (to talk about) of 'good response' and 'keeping promises'
19:18:02 <TrueBrain> at a certain stage I even started to publish ebuilds myself
19:18:07 <TrueBrain> which is a bad idea in all scenarios
19:18:33 * andythenorth wonders about asking a question
19:18:38 <CrazyTB> sunrise (and maybe gamerlay) are "solutions" for such problems.
19:18:45 <TrueBrain> at a certain moment someone decided OpenTTD should be EAPI 2, while the stable portage could only handle EAPI 1
19:18:51 <TrueBrain> disabling OpenTTD for many many many Gentoo users
19:19:33 <TrueBrain> when complaining, the reply was: yeah, we should all switch to EAPI 2 ASAP
19:19:40 <TrueBrain> .... but your stable portage DOES NOT SUPPORT IT!
19:19:46 <TrueBrain> at that time, I am tempted to get a gun
19:19:50 <Rubidium> TrueBrain: Gentoo OpenTTD users shouldn't be using anything stable
19:20:27 * Wizzleby takes some notes, lots of feedback =D
19:20:45 <Rubidium> either run stable with a known broken openttd or run an (according to Gentoo) unstable OpenTTD
19:20:49 <TrueBrain> lol, I see my 'nightly' ebuilds are still being generated :)
19:21:00 <TrueBrain> I should disable that, and remove it :)
19:21:11 <Wizzleby> Rubidium: every arch except amd64 FINALLY stabilized 0.7.5 XD
19:21:29 <Rubidium> Wizzleby: that's been the case for like 4 months already
19:21:32 <Wizzleby> still, I hope that the stabilization process will go quicker when there's a maintainer to actually keep up with it
19:21:33 <TrueBrain> well, they delay in 'stable' mark is something that I can understand ... in most cases
19:21:47 <TrueBrain> that just is native to Gentoo, and something someone should accept
19:22:52 <TrueBrain> had to hack a few scripts in order to make that possible under Debian :)
19:23:15 <TrueBrain> RMD160 was tricky :)
19:23:47 <glx> TrueBrain: but openttd (normal) is very outdated
19:24:19 <TrueBrain> yeah, at that point I gave up on Gentoo
19:24:59 <glx> I think you can just remove packages.openttd.org
19:25:03 <TrueBrain> I started because they didn't had 0.6.3 in their portage while it was released for 3+ months .. not even the unstable was there
19:25:10 <TrueBrain> but getting my 0.6.3 accepted turned out to be impossible
19:25:21 <Wizzleby> Rubidium: btw, does LTO work for you with gcc 4.5.0 (or latest 4.5 branch from svn)
19:25:26 <TrueBrain> but I need to find the scripts that generate the data
19:25:44 <TrueBrain> Rubidium: can you remove the DNS entry of packages.openttd.org?
19:25:46 <Rubidium> Wizzleby: it did work, but currently it kinda fails
19:25:48 <glx> maybe we'll get complains about the removal ;)
19:25:59 <Wizzleby> Rubidium: undefined references to 'someltothing'?
19:26:11 *** lobstah has joined #openttd
19:26:23 <andythenorth> Yexo: will new airports make it possible to have a helicopter load whilst hovering?
19:26:24 <Wizzleby> during linking I mean
19:28:06 <glx> andythenorth: I think first step is to have working airports ;)
19:28:22 <Wizzleby> glx: hang on, will get the actual output
19:28:37 <Rubidium> Wizzleby: lto1: internal compiler error: in input_gimple_stmt, at lto-streamer-in.c:1108
19:28:59 <TrueBrain> there, packages.openttd.org disabled
19:32:21 <Wizzleby> Rubidium: hm, that's different from mine, whyich is a whole bunch of undefiend references
19:32:45 <Rubidium> well, I guess lto isn't finished yet
19:33:09 <CrazyTB> just curious... what is LTO?
19:33:11 <Rubidium> and lto has had a lot of problems with lto
19:33:38 <Rubidium> link to optimisation
19:33:52 <Wizzleby> Rubidium: yeah that's for sure, lto breaks pretty much every third thing I throw at it ;)
19:34:40 <yorick> link time optimisation?
19:34:59 <frosch123> yorick: it is not about faster linking :p
19:35:19 <yorick> frosch123: but it is about optimisation(inlining) at link time?
19:36:55 <frosch123> i am sure wiki knows it better than i could explain
19:40:10 <glx> frosch123: source required ;)
19:41:16 <frosch123> [21:37] <frosch123> i am sure wiki knows it better than i could explain <- there
19:41:44 <Wizzleby> TrueBrain: reading back about your EAPI issues.. these days, its different. These days, games.eclass doesn't support the latest stable EAPI ;)
19:50:49 *** ChanServ sets mode: +v tokai
19:52:17 *** fonsinchen has joined #openttd
20:06:01 *** Progman has joined #openttd
20:09:23 <Wizzleby> hm, well, we're getting somewhere now, but I still fail to grok the logic behind whether to use zlib at configure time or not as it is stated in the legacy of this ebuild
20:09:43 *** Brianetta has joined #openttd
20:10:04 *** asnoehu has joined #openttd
20:10:43 <Wizzleby> the result of said logic is that one can get built against zlib regardless of the zlib useflag, which leads me to suspect it is useless as a use flag
20:11:09 <asnoehu> what do you mean with "Continental breakfast only"
20:12:18 <blathijs> Hmm, dunno who put that in the topic. Sounds funny, no clue what it means, though :-p
20:13:07 <CrazyTB> Can we "rotate" the view?
20:17:46 <Rubidium> Wizzleby: huh? what about zlib?
20:19:17 <planetmaker> asnoehu: we had for weeks a "Full English breakfast only". Now it's time for continental one. Or it would be discriminating ;-)
20:19:54 <planetmaker> Terkhen: no or not yet? ;-)
20:20:49 <Terkhen> not until someone crazy enough picks that up
20:20:50 <asnoehu> what would I have to think about :S
20:20:58 <asnoehu> what is a continental breakfast :O:
20:21:30 <planetmaker> Terkhen: I guess so :-)
20:21:45 <planetmaker> I see it principally feasable. But LOTS of work
20:21:53 <planetmaker> both coding, more so on the graphics side
20:22:18 <Rubidium> Wizzleby: heh, it's gentoo that wants *everything* configurable
20:22:26 <SmatZ> Wizzleby: would you prefer some "you enabled PNG, but not ZLIB, please add ZLIB USE flag"?
20:22:47 <Rubidium> SmatZ: actually, libpng depends on zlib
20:23:06 <Rubidium> and freetype depends on zlib, fontconfig depends on freetype
20:23:20 <planetmaker> he. Little way around zlib, I guess
20:23:21 <Yexo> <andythenorth> Yexo: will new airports make it possible to have a helicopter load whilst hovering? <- yes
20:23:23 <Wizzleby> Rubidium: I'm not even against letting that level of configurability, but I don't see why try if the logic you use is broke XD
20:23:39 <Wizzleby> speaking of even giving a zlib useflag when other use flags will force zlib on :)
20:24:09 <planetmaker> Wizzleby: you can turn everything off. And keep zlib. No way to turn it off. Good or bad?
20:25:16 <Wizzleby> planetmaker: hard to say from my position, whether it is good or bad. Not even sure in what situations someone would want/need to turn zlib off
20:25:25 <planetmaker> ./configure --without-png --without-freetype --without-fontconfig --without-zlib
20:25:50 <planetmaker> Wizzleby: so you say you don't understand it but call the logic flawed? Strong words...
20:26:20 <Wizzleby> planetmaker: I don't believe I said flawed, I said I don't grok it
20:26:47 <planetmaker> [22:23] <Wizzleby> Rubidium: I'm not even against letting that level of configurability, but I don't see why try if the logic you use is broke XD <-- yeah. "broke logic"
20:27:03 <Rubidium> Wizzleby: from OpenTTD's point of view, what's the point of linking to zlib but not using it?
20:27:38 <Rubidium> i.e. if you use freetype or libpng you implicitly link to zlib already, so openttd can use that too
20:27:53 <Rubidium> same as using fontconfig implies you want freetype
20:27:53 <Wizzleby> planetmaker: yes, with reference to the specific way the ebuild delivers the option. It gives a zlib use flag, implying that compiling with USE=-zlib will disable zlib which is not universally true
20:28:19 <Rubidium> Wizzleby: in that case -zlib should disable freetype and png
20:28:51 <andythenorth> Yexo: great.....helicopter logging :)
20:28:51 <Rubidium> and disabling freetype should disable fontconfig
20:28:51 <fonsinchen> Thanks for the build.
20:29:21 <planetmaker> andythenorth: heli-skiing for tourist resorts :-P
20:30:00 <Rubidium> and then you might ponder the use of icu when freetype/fontconfig is disabled as I doubt there'll ever be a (New)GRF with an Arabic or Hebrew font
20:31:08 <Yexo> andythenorth: trunk cn do that already, just draw a lower building for the heliport
20:31:17 <Wizzleby> Rubidium: thanks for the feedback
20:31:58 *** Weeknie has joined #openttd
20:32:16 <andythenorth> Yexo: the shadow goes screwy (IIRC?) and the blades stopping produces a certain strange effect :)
20:32:42 <Wizzleby> planetmaker: you too, though I'm still not sure what exactly it is you're suggesting (still listening though, in case you decide to be more explicit)
20:33:05 <Yexo> the shadow will be tricky to do correct
20:33:39 <planetmaker> I don't suggest any change as I don't consider the current situation flawed
20:34:35 <frosch123> Yexo: what about the rotor? does it stop when loading?
20:34:38 <Wizzleby> planetmaker: fair enough
20:34:52 <Yexo> frosch123: I'm not sure how that currently works
20:36:06 <frosch123> oh, in that case, i guess it is controlled by aircraftcontroller, and iirc vehiclecontrollers are not called when stopped or loading
20:36:50 <Yexo> just found that it's handled by HelicopterTickHandler
20:37:00 <Yexo> which just checks the speed of the vehicle
20:37:04 <Yexo> spd==0 -> rotor = stopped
20:38:24 <frosch123> if (v->current_order.IsType(OT_LOADING) || (v->vehstatus & VS_STOPPED)) { <- it even check directly for loading
20:38:48 <Alberth> no commando-style unloading of helicopters?
20:39:57 <Wizzleby> planetmaker: fwiw, I still consider the presentation of the use flag broken. It does not at all communicate its use, hence my questions, as to how to specify to a user what exactly the effects of setting it would be
20:40:06 <Yexo> is that code ever executed? can u->cur_speed be != 0 while the vehicle is loading/stopped?
20:40:11 <Wizzleby> if nothing else, it needs a metadata entry explaining it
20:43:16 <frosch123> Yexo: i guess u->cur_speed != v->cur_speed
20:43:40 <frosch123> likely stopping the vehicle only stops v->cur_speed, while the rotor is controlled independently
20:43:40 <Yexo> ah, I totally overlooked that
20:43:45 <Rubidium> Wizzleby: would it help "the powers" to consider stabilising a later version of OpenTTD if you create a bug report for each of the CVEs fixed in 1.0.1?
20:44:08 <Rubidium> or might it better to wait till your updates/rewrites are pushed?
20:44:33 <Wizzleby> Rubidium: I think it might indeed help, do you have a list of those CVEs handy for me? I can post the bugs once I finish this cleanup
20:49:54 <CIA-6> OpenTTD: alberth * r19848 /trunk/src/newgrf_gui.cpp: -Fix (r19837): Center the texts of the inactive newgrfs.
20:51:34 <TrueBrain> Rubidium: you just once had to use that website, not? :)
20:52:59 <Alberth> it is the 2nd time already :)
20:54:00 *** ChanServ sets mode: +v tokai
20:55:05 *** Razaekel has joined #openttd
20:55:20 <Razaekel> how do you get 100% transported for a primary industry?
20:55:23 <TrueBrain> damn, I wrote the new network in 0.3.5? :|
20:56:54 <Alberth> it gets old all by itself :)
20:57:12 <TrueBrain> yeah .... and that makes me old too :(
20:58:14 <orudge_> 6 years since I persuaded Ludde to release OpenTTD at all though, too
20:58:26 <orudge_> I was but 16 then, madness
20:59:15 <orudge_> and near enough 10 years since I started my TT site
20:59:16 <Alberth> so young and wise already :)
21:00:35 <Beklugas> hhoooo... :( Ronnie James Dio is dead
21:01:01 * Beklugas is sad. will not celebrate the End Of Day with usual excitement
21:01:28 *** Beklugas is now known as Belugas
21:02:29 <Alberth> "..mostly known as the invisible singer of the hit with the animated frog.."
21:04:28 * andythenorth needs to man up and start coding some recolor sprite tables
21:04:40 * andythenorth wonders whether it can be done programmatically
21:04:57 <andythenorth> as it's going to have to account for 2CC and is therefore brainf*ck
21:06:29 <andythenorth> Alberth: nice column action on the newgrf gui
21:06:55 <Alberth> yeah, I liked it too after coming up with the idea :)
21:07:25 <Alberth> coding it was a lot less fun though, I forgot the mess of handling widget sizing and positioning, too many parameters
21:07:46 <andythenorth> I wouldn't have dared suggest something that complex :)
21:07:53 <Razaekel> thanks for the link alberth, but it doesnt give me insight as to HOW to get 100% transported at a industry
21:08:15 <Alberth> I am not even sure that is possible.
21:08:36 <Razaekel> alternatively, how to get it as high as possible
21:08:44 <Yexo> Razaekel: make sure you have a 100% rating at the station for the cargo
21:09:00 <andythenorth> Alberth: you could move the text input for parameters into the newgrf window? But perhaps then there's no way to save it....?
21:09:08 <Yexo> how you can do that is perfectly explained by that very same wiki page
21:09:32 <Alberth> andythenorth: what do you mean?
21:09:40 <Razaekel> yea, just hit an advertising campaign
21:09:57 <andythenorth> instead of opening a small window / dialog for parameters, just put the input box for them in the 'info' area
21:10:20 <andythenorth> but then how does the user confirm....
21:10:30 <Rubidium> Razaekel: only in the late electrified trains/begin monorail/maglev you can reach a 100% station rating without advertising
21:10:42 <Razaekel> what should i do after i get 100% rating?
21:10:58 <Alberth> stop caring about goals?
21:11:02 <Yexo> connect another industry to your station?
21:11:12 <Alberth> connect all industry :)
21:11:12 <Rubidium> then the industry will get a 100% rating as well
21:11:26 <Rubidium> although, it is quite hard to keep a 100% station rating
21:11:34 <Razaekel> so % transported depends on industry rating at the station?
21:12:04 <Rubidium> as described in the section called "Cargo delivery to stations"
21:12:09 <Razaekel> i did a medium advertising campaign, but rating hasnt budged
21:12:21 <Rubidium> then the station wasn't within 15 tiles of the town center
21:12:23 <Alberth> andythenorth: didn't the notes of frosch state something about changing the parameters? perhaps we better wait for that
21:13:37 <Razaekel> large campaign kicked it up to 100%
21:14:03 <Rubidium> (almost) all distances are manhattan distances in OpenTTD
21:15:36 <CIA-6> OpenTTD: alberth * r19849 /trunk/src/newgrf_gui.cpp: -Fix: Center sprite and text seperately in the newgrf gui active list.
21:19:55 <andythenorth> Alberth: in the side-by-side list view, it would be better if the two lists were aligned vertically (top edges)
21:22:57 <Alberth> and I was already very happy about their alignment at the bottom, equal with the info panel :p
21:23:39 <andythenorth> everyone's a critic :P
21:24:01 <andythenorth> it's the titles that should align, it's a bit weird not too
21:25:20 <andythenorth> and aligning the bottom *as well* :D
21:26:00 <andythenorth> hmmmm.......bedtime for me :o
21:26:00 <Alberth> you mean the two panels should be aligned at the top and the bottom?
21:26:36 <Alberth> you can safely ignore that, I have done that for the past hour. you don't die immediately, I found out
21:27:07 <andythenorth> there would be other ways to do it....'check online content' could move above 'inactive'
21:27:26 <andythenorth> or you could move 'Active' above the presets
21:28:02 <andythenorth> I guess 'Check online content' is pretty important for a lot of players
21:30:03 <andythenorth> anyway....bed time :)
21:43:31 <z-MaTRiX> everybody coding/gaming ?
21:44:44 <PeterT> There are tons of server channels that you probably don't know about ;-)
21:45:14 <z-MaTRiX> well you can't be sure about that
21:45:43 <PeterT> Well, I've /whois'd you, and you aren't on any of the channels
21:46:16 <z-MaTRiX> coz i came only here ;>
21:46:37 <PeterT> so if you know about them, why do you ask if we are gaming?
21:47:25 <z-MaTRiX> you don't play the game just code all day?
21:53:54 * andythenorth decides now is not the time to start jQuery hacking
22:17:06 *** Coco-Banana-Man has quit IRC
22:36:12 *** NukeBuster has left #openttd
22:36:50 <Wizzleby> hm. So if I do --with-midi='/usr/bin/timidity', I get sound via the extmidi driver, but the libtimidity driver still gives me issues
22:37:14 <PeterT> z-MaTRiX: so what gaming-channels do you know of?
22:37:24 <Rubidium> libtimidity was meant for something like pocketpc or so
22:39:51 <peter1138> heh, you don't need to recompile to change the executable that extmidi uses
22:41:29 <Rubidium> and might very well not work at the moment due to it not being used
22:46:38 <glx> wasn't libtimidity for psp ?
22:47:18 <Rubidium> glx: same kind of thing... some small device platform of which the port was never finished
23:18:00 *** JVassie has joined #openttd
23:37:40 <Rubidium> Wizzleby: gcc 4.6 (r159516)'s LTO seems to work fine with OpenTTD
23:39:27 <SmatZ> Rubidium: I don't have such experience
23:39:32 <SmatZ> it fails to link for me
23:39:53 <SmatZ> last time it ended with undefined references...
23:40:08 <SmatZ> also, if gcc asserts are enabled, it ICEs
23:41:54 <Rubidium> SmatZ: but you've gotten problems when I didn't have them quite often
23:42:17 <Rubidium> the LTO binary is a whopping 0.86% smaller
23:42:39 <SmatZ> Rubidium: it seems something is wrong with my system :) maybe different locale causes different order of files at command line
23:45:32 <Rubidium> not that it's faster (with regression)
23:46:44 <Rubidium> without lto: [2.600..2.622], with lto: [2.627..2.652]
23:46:57 <SmatZ> it's hard to measure a difference with that short runs :)
23:48:24 <Rubidium> but yes, it only tests a small area of OpenTTD
23:48:40 <SmatZ> I am afraid most of it is scanning of GRF files
23:48:56 <Rubidium> little vehicle handling and such, which is where LTO might have the advantage
23:49:46 <SmatZ> I am not sure how far is de-virtualization in gcc
23:50:03 <SmatZ> by coincidence, just today was one related commit :)
23:50:23 <SmatZ> it would be nice if gcc knew there are no derived classes from Train/RoadVeh/Ship/Aircraft
23:50:51 *** roboboy has joined #openttd
23:56:41 *** theholyduck has joined #openttd
23:59:52 *** Keyboard_Warrior has joined #openttd
continue to next day ⏵
