IRC logs for #openttd on OFTC at 2010-08-25
⏴ go to previous day
00:27:49 <TruePikachu> ^^ that has the new files
00:30:01 <TruePikachu> I'm not sure if I got the category correct, though
01:13:36 <TruePikachu> Oh, so your server keeps kicking you?
01:20:23 *** TruePika1hu has joined #openttd
01:21:25 *** TruePika1hu is now known as TruePika
01:21:37 * TruePika was not aware of connection loss
01:22:13 <ccfreak2k> Connection gain, connection loss.
01:22:34 * TruePika is wating for TruePikachu to ping timeout
01:22:38 *** zodttd2 has joined #openttd
01:22:57 <TruePika> No, I wasn't aware that my connection dropped
01:23:05 *** TruePika is now known as TruePikachu
01:35:13 <TruePikachu> How much more processor-intensive is 32bpp verses 8bpp?
01:37:13 <ccfreak2k> TruePikachu, it was actually faster when I used the opengl blitter.
01:40:54 <TruePikachu> nvm for right now, gtg
02:26:11 *** rhaeder1 has joined #openttd
03:03:26 *** ChanServ sets mode: +v tokai
03:25:05 *** ChanServ sets mode: +v tokai
03:47:07 *** fmauneko has joined #openttd
03:50:42 *** Xrufuian has joined #openttd
04:14:07 *** ChanServ sets mode: +v tokai
04:56:24 *** Eddi|zuHause has joined #openttd
05:02:39 *** fmauneko has joined #openttd
06:09:39 *** Kurimus has joined #openttd
06:35:19 *** TomyLobo has joined #openttd
06:37:17 *** Goulpy is now known as Muxy
06:38:17 *** ^Spike^ has joined #openttd
06:41:27 <Eddi|zuHause> new sports: "Duke Nukem Mikado" - "who releases first, looses"
06:42:41 <planetmaker> George isn't that bad :-)
06:42:59 <planetmaker> And George clearly said that he stops LV5 until <something I forgot>
06:43:08 <planetmaker> Some FS entry he would like to see resolved
06:44:08 <Eddi|zuHause> yeah, improved curvature information
06:44:30 <Eddi|zuHause> i implemented that, but it wasn't included in trunk, afair...
06:44:35 <planetmaker> yeah, sounds like one of the things he likes
06:45:30 <Eddi|zuHause> fs#2521 it might be
06:49:20 <planetmaker> and he's somewhat right: without anything new to add technically there's no point to up the version from LV4 to LV5.
06:49:35 <planetmaker> Might of course be that there are meanwhile other things which could be done
06:50:19 <Eddi|zuHause> well... the patch is there, it's just untested...
06:50:54 *** Cybertinus has joined #openttd
06:52:40 <Eddi|zuHause> "Systemmanager Server (m./w.) - Schwerpunkt Unix" <-- anyone think i should apply for such a job?
06:56:05 <planetmaker> If you like it and the company, its work-style and if the payment is ok
06:58:49 <Eddi|zuHause> i'm more a person of the theory, but i don't want to stay at the university, and it's difficult to find a job that matches that, if you also want to stay in the region...
07:04:02 <planetmaker> he. That's two limitations :-)
07:04:11 *** devilsadvocate has quit IRC
07:04:12 <planetmaker> That makes it more difficult indeed
07:08:20 <dihedral> looks like you had an interesting night :-P
07:08:51 *** devilsadvocate has joined #openttd
07:16:12 *** JVassie has joined #openttd
07:16:29 <Eddi|zuHause> "Apple hat die Wortmarke IPOD offenbar nicht nur für MP3-Spieler und verwandte Gerätschaften angemeldet, sondern unter anderem auch für "Geräte und Behälter für Haushalt und Küche"."
07:16:55 <planetmaker> That's indeed the most interesting sentence there and leaves one wondering
07:17:12 <dihedral> the company is allowed to name any other product "eiPOTT", just not that one :-P
07:17:47 <dihedral> i saw one here, and was wondering if i should buy one before they get banned :-P
07:19:13 <planetmaker> I definitely would
07:19:53 <dihedral> yeah, but not for 8 eur
07:20:13 <dihedral> it's an egg cup in the shape of an ipod :-P
07:21:04 <Eddi|zuHause> it's clearly one of the prime examples how patents "help" innovation
07:24:25 <planetmaker> dihedral: they make awesome presents
07:24:37 <planetmaker> like "Darling, I brought you a brand new eipott" ;-)
07:25:06 <dihedral> i think i'd only do that once with my darling :-P
07:25:25 <planetmaker> personally I'd laugh my head of
07:25:40 <planetmaker> both, giving it away and receiving it
07:25:42 <dihedral> well - if it were a birthday present :-P
07:26:02 <planetmaker> of course it doesn't work, if an iPod was asked for. But...
07:26:15 <Eddi|zuHause> they'd be a cool "Prasselgeschenk"
07:26:26 <dihedral> jeah - junk-wichteln
07:27:07 <planetmaker> auch genannt "Schrottwichteln" ;-)
07:35:35 * dihedral had fun reading the backlog from the night :-D
07:37:23 <Eddi|zuHause> there wasn't really much going on, what was so funny?
07:38:18 <planetmaker> hm, what was the (new) log URL?
07:40:41 <Eddi|zuHause> i don't know what happened to mikegrb... i think we kicked him once...
07:56:44 <Rubidium> so now we need to use a few hundred euro iPod to break an egg? Seems like a waste of money
08:06:19 *** lordaro has joined #openttd
08:07:53 <planetmaker> damn :-( One of my monitors died over night :S
08:09:03 <Rubidium> and you were too late for CPR?
08:10:10 * dihedral moans in silence :-P
08:10:51 <Rubidium> lordaro: you shouldn't have re-added the post requesting the sources of tb's tournament thingy after I read your post, you subsequently removed it and I added the sources to my post
08:11:53 <dihedral> not that they would cleanly apply i guess ....
08:12:42 <dihedral> i was not quite clear then i take it :-P
08:23:11 *** Progman has joined #openttd
08:24:35 *** lordaro has joined #openttd
08:28:09 *** trebuchet has joined #openttd
08:35:29 <TruePikachu> Someone should take a look at 4080 and contact the creater if they have not been contacted.
08:36:42 <TruePikachu> The report takes second place for the prize for 'bug report with least amount if information given', first prize went to 2 identical photographs of a computer, 'before' and 'after'
08:37:15 <TruePikachu> I told them to attach crash.dmp - crash.sav doesn't seem to apply to server list problems
08:40:26 <Eddi|zuHause> people who report bugs automatically get an email when someone writes a comment
08:40:43 <Eddi|zuHause> but thanks for caring
08:40:46 * TruePikachu re-read the crash log, and thinks that McAfee may possibly be the problem
08:41:30 <TruePikachu> They may be using McAfee AV software; they are running McAfee SiteAdviser according to crash.log
08:42:33 <SmatZ> 3rd party tools sometimes cause problems in openttd, yes
08:42:34 <TruePikachu> On the XP+McAfee box here, McAfee has caused the majority of network problems, even with the firewall practically disabled
08:42:47 <TruePikachu> It even crashed Windows 3 times in a row!
08:43:13 <TruePikachu> boot->Login screen->5sec->reboot
08:43:37 <TruePikachu> Once in safe mode, I found the problem to be the antivirus scanner
08:44:33 <TruePikachu> (and SiteAdviser seems to never hook into IE/FireFox, therefore slowing the system by 2-3%)
08:45:04 <TruePikachu> (and when it does, you get 5-10 SiteAdviser icons in a row at the end of search results -_-)
08:47:05 <TruePikachu> For FS#4079, did anyone remove the attachments?
08:48:25 <SmatZ> TruePikachu: uploading of attachments sometimes fails for some reason
08:48:27 <dihedral> i hate it when plugins do not work as desired
08:48:40 <SmatZ> the dev team has decided it's user fault because we were never able to reproduce the problem
08:49:32 * TruePikachu will re-upload the images, but swears they uploaded correctly earlier today
08:50:08 <TruePikachu> O_o imagine if it failed on FS4080
08:51:46 <SmatZ> hmm why people love to upload crash.zip instead of separate files
08:52:03 <SmatZ> so I have to download the archive in order to view crash.log...
08:52:07 <TruePikachu> Especially as a zip; it is ugly compression
08:53:07 <gynter> Hello, anyone compiled openttd on freebsd?
08:53:24 <TruePikachu> gynter: No, but I've compiled on Linux ;)
08:54:24 <SmatZ> probably fixed some freebsd problem
08:54:33 <SmatZ> so at least the reported tried to compile openttd there
08:54:45 <TruePikachu> ^^ seems like a relativly useless @ command for me
08:55:18 <gynter> configure script is fine, gmake cries about missing lzo/lzo1x.h
08:55:25 <gynter> thou I have lzo installed
08:57:13 <gynter> freebsd 7.1 & latest openttd stable source
08:57:17 <Rubidium> does Debian/kfreebsd count?
08:57:33 <SmatZ> gynter: do you have some lzo(2)-devel package installed?
08:57:38 <TruePikachu> Can you execute the command from '/'?
08:58:17 <TruePikachu> ^^ yes, I hate those kinds of package dependancies
08:58:59 <TruePikachu> If you have it all installed, sounds like the libUSB problem I've had when compiling TiLP
09:00:05 <gynter> does --enable-dedicated also require data files?
09:00:06 <TruePikachu> Stupid thing that 1.x and 0.x are not compatable :(
09:00:47 <Eddi|zuHause> there's some needed information e.g. for land generation in there
09:01:47 <Eddi|zuHause> sound and music is not needed
09:02:13 <gynter> header files are in /usr/local/include/lzo
09:02:26 <gynter> for lzo2 and in /usr/local/include for lzo
09:02:49 <TruePikachu> Is the missing file in there?
09:02:52 <Eddi|zuHause> and if you add that path to CFLAGS?
09:03:16 <Eddi|zuHause> gynter: mit be a bug in ./configure
09:03:19 <TruePikachu> I know it may seem like a dumb question, but it won't hurt to double-check
09:04:10 <gynter> lzo1x.h is in both dirs
09:04:34 * TruePikachu has no clue as to the problem then, as that has never happened to him
09:04:35 <Rubidium> it should just work with /usr/local/include/lzo/lzo1x.h
09:05:00 <Rubidium> maybe config.log can give a clue?
09:05:56 <TruePikachu> Are you able to read the file? If not, the problem could be with permissions...I've had that happen once, for some reason...
09:06:08 <gynter> trying /usr/local/include/lzo/lzo1x.h... found
09:06:08 <gynter> checking lzo2... found
09:06:14 <gynter> trying /usr/include/lzo/lzo1x.h... no
09:06:40 <gynter> that means it found the header thou
09:07:02 <TruePikachu> Well, then 'sudo cp /usr/local/include/lzo/lzo1x.h /usr/include/lzo/lzo1x.h' :)
09:07:24 <TruePikachu> Or, you could do a symbolic link, replacing 'cp' with 'ln -s'
09:07:47 <gynter> and /usr/include is symlink to basejail
09:08:07 <Eddi|zuHause> TruePikachu: that is _definitely_ the wrong thing to do
09:08:28 <gynter> well but it did found it in /usr/local/include/lzo too as the logfile says
09:08:40 <gynter> afaik this should work fine
09:08:45 <TruePikachu> Well, all I know about FreeBSD is that the archetecture is similar to Linux
09:09:14 <TruePikachu> Try to prevent the check on /usr/include
09:11:27 <Rubidium> could you paste config.log somewhere? pastebin.com or so?
09:18:01 <peter1138> right... where's the RISC OS port?
09:29:42 <Rubidium> hmm, that config log looks fine, so it fails somewhere during compilation?
09:33:33 <Rubidium> gynter: it sounds like /usr/local/include isn't a "search" path for your gcc
09:34:42 <Rubidium> gynter: does ./configure --disable-builtin-depend help you
09:39:22 <Rubidium> gynter: does ./configure CFLAGS=/usr/local/include help?
09:39:42 <Rubidium> and it's gmake that is having the trouble and not gcc?
09:41:43 <Rubidium> so it's gcc that's not finding the file, i.e. the include path misses /usr/local/include
09:41:59 <Rubidium> and I (ofcourse) just gave you a wrong test
09:42:12 <Rubidium> gynter: ./configure CFLAGS=-I/usr/local/include
09:42:23 <Rubidium> slightly different than the previous, but I forgot the -I
09:42:34 <gynter> remove disable-builtin-depend?
09:43:05 <Rubidium> if that pasted error is the error you've always had, then you can remove the disable-builtin-depend
09:43:16 <Rubidium> though the strndup thing worries me a bit
09:47:02 <gynter> yea, lots of strndup stuff
09:49:20 <Rubidium> oh, they added strndup in FreeBSD 7.2
09:53:33 <Rubidium> this whole strndup stuff being "unreliably" available is just annoying. I guess configure needs to actively test for it's existance (yay for autotools/autoconf style :()
09:53:58 <gynter> hmm, is there a way to specify custom installation directory?
09:54:12 <Rubidium> gynter: see configure
09:54:15 <Rubidium> gynter: see configure --help
09:54:31 <gynter> thans, anyway, it compiled now
09:54:54 <Rubidium> it linked even due to those strndup warnings? No duplicate symbols or something?
09:58:21 <Rubidium> then one small test, does changing "#if defined(_GNU_SOURCE) || (defined(__NetBSD_Version__) && 400000000 <= __NetBSD_Version__)" to "#if 1" fix all the strndup warnings still make it link?
09:58:32 <Rubidium> that at the bottom of string_func.h
10:05:22 <gynter> icon-dir and icon-theme-dir are required for desktop icons etc?
10:05:50 <gynter> is it possible to disable creation of those? i only need it for dedicated server
10:16:25 <gynter> Rubidium, it fixed the warnings
10:20:47 <gynter> do I need all Open* stuff or only OpenGFX?
10:36:36 <gynter> has configuration file changed alot, comparing to 0.6.3?
10:37:17 <Eddi|zuHause> 0.6 is a long time ago
10:37:52 <Eddi|zuHause> can you be more specific?
10:38:14 <Eddi|zuHause> openttd will load old config files and rewrite them
10:39:23 <gynter> nevermin, i'll just remake the server conf
10:41:58 <Eddi|zuHause> he asked me why i was calling him a troll
10:42:18 <Eddi|zuHause> i didn't have the heart to answer "because you're not exactly splurting of competence"
10:44:41 *** Adambean has joined #openttd
10:47:38 <Eddi|zuHause> random thought: if you check the "related object" of a wagon (i.e. the engine). is the spec somehow extendible so you can submit a parameter to ask for the Nth vehicle in the chain instead?
10:48:01 <Eddi|zuHause> as a more generic approach to fs#2521
10:52:22 <Hirundo> The approach of random action2 type 84 should be applicable to varaction2 as well
10:55:27 <Eddi|zuHause> i think it should need 4 ways of addressing: {absolute, relative} and {whole chain, chain of same ID}
10:56:10 <Eddi|zuHause> ("and" standing for cartesic product here)
11:01:45 <Hirundo> Randomaction2 allows 3 of those (all except relative in chain of same ID)
11:02:26 <Hirundo> There are still some bits free, though
11:03:04 *** KenjiE20 has joined #openttd
11:03:37 <Eddi|zuHause> crazy people might also want to address the end, but that could be done by providing negative numbers to "absolute", if that has at least 8 bits
11:04:00 <Eddi|zuHause> a chain may be up to 100 vehicles
11:04:43 <Hirundo> That does not work, currently (max count is 16)
11:06:26 <Eddi|zuHause> whoever wrote that spec... :p
11:06:58 *** fmauneko has joined #openttd
11:12:28 *** Devroush has joined #openttd
11:19:42 <gynter> is there example dedicated server only config file somewhere for 1.0.3?
11:20:15 <dihedral> ./openttd will create a config file for you
11:20:23 <dihedral> you can then edit it
11:22:37 *** Celestar has joined #openttd
11:26:42 <Celestar> other than I'm ill ... not too shabby
11:26:58 <Celestar> and I'm having a fight with my ubuntu
11:27:36 <Eddi|zuHause> no, openttd does not support "enhanced tunnels" [as in rail over the tunnel entrance]
11:27:46 <Eddi|zuHause> and to my knowledge, also nobody is working on it
11:28:04 <Celestar> I had a branch for that.
11:28:27 <Eddi|zuHause> it should be very similar to custombridgeheads
11:28:42 <Eddi|zuHause> with some graphical issues
11:28:44 <Rubidium> dihedral: you should know by now that a NewGRF can't implemented enhanced tunnels
11:29:02 <Celestar> yeah but cbh is hard with our virtual bridge thingy
11:29:25 <dihedral> Rubidium, the newgrf itself cannot - hence i am asking if it's in openttd in the meantime
11:29:40 <Eddi|zuHause> i remember the biggest issue was signal on the bridgehead, and maybe some stuff with turning around
11:30:04 <Celestar> yeah, in 1 out of 4 cases the train disconnected on turning around
11:30:19 <Rubidium> dihedral: ofcourse not, otherwise you'd've seen a commit log saying so
11:30:49 <dihedral> i recall not being around for a good few hundred revisions :-P could have checked the logs, true
11:31:36 <Eddi|zuHause> the logs might not be totally conclusive with regards to such features... e.g. try searching for "implement tram support" :)
11:33:39 <dihedral> it would have definately been marked with -[Ff]eature(?:ete|ish)?
11:39:40 *** wollollo has joined #openttd
11:42:49 *** fmauneko has joined #openttd
11:44:20 <Eddi|zuHause> @openttd commit 9923
11:44:20 <DorpsGek> Eddi|zuHause: Commit by rubidium :: r9923 /trunk (18 files in 5 dirs) (2007-05-25 22:07:40 UTC)
11:44:21 <DorpsGek> Eddi|zuHause: -Add: support for Action 0 Road vehicles, property 1C, bit 0.
11:44:39 <Eddi|zuHause> i don't think that matches ;)
11:45:54 <Rubidium> but name me what NewGRF bit is about rail on tunnelheads :)
11:46:18 <Eddi|zuHause> that should rather be a TTDP flag?
11:50:30 *** devilsadvocate has quit IRC
12:02:54 *** trebuchet has joined #openttd
12:02:54 *** ^Spike^ has joined #openttd
12:02:54 *** weber.oftc.net sets mode: +o orudge
12:02:56 *** ChanServ sets mode: +v orudge
12:05:42 *** Eddi|zuHause2 has joined #openttd
12:06:29 <Eddi|zuHause2> soo... who holds the plug in his hand?
12:07:50 <dihedral> it must be orudge, he just wanted to hide his join!
12:12:43 *** Eddi|zuHause2 is now known as Eddi|zuHause
12:16:09 *** devilsadvocate has joined #openttd
12:23:54 *** fmauneko has joined #openttd
12:24:03 *** fmauneko has joined #openttd
12:27:04 *** fmauneko is now known as fmauNeko
12:29:20 *** russell_h has joined #openttd
12:29:50 *** Kurimus has joined #openttd
12:31:17 *** Rubidium has joined #openttd
12:31:17 *** charm.oftc.net sets mode: +ov Rubidium Rubidium
12:43:15 * yorick thinks ludde would do that
12:46:14 *** Rubidium_ has joined #openttd
12:48:54 <gynter> is ; comment in openttd.cfg?
12:49:28 <Eddi|zuHause> it's the same format as .ini files
12:49:48 <Eddi|zuHause> probably # works
12:50:16 <gynter> hmm ; works, but it removes the commented lines
12:53:49 *** fmauNeko_ has joined #openttd
12:58:14 <Belugas> boing boing planetmaker :)
12:59:50 <Eddi|zuHause> i only know boeing, and they're not making planets, only planes, without t
13:01:13 *** fmauNeko_ is now known as fmauNeko
13:08:00 <Eddi|zuHause> i know :) i was just making fun of the close spellings ;)
13:09:08 *** Rubidium_ is now known as Rubidium
13:13:26 <Rubidium> Eddi|zuHause: it's the rdns of rbijker.net (yes multiple things are hosted there) because it didn't connect over IPv6 to OFTC (in which case it should be getting rbijker.net as rnds)
13:14:22 <Rubidium> unless IPv6 rdns doesn't work, in which case I blame orudge
13:14:31 <Rubidium> though I can't be bothered that much by rdns-es anyhow
13:14:59 <VVG> Recent trunk gives me a warning about old opengfx. Where do i get a new one?
13:16:13 <gynter> is it possible to remove/add newgrf-s to existing scenario?
13:16:24 <VVG> oh, no new stable opengfx yet?
13:16:53 <Ammler> there was no stable opengfx yet at all
13:17:24 <VVG> what about the one on bananas?
13:17:41 <Eddi|zuHause> gynter: only in single player, and it's not recommended
13:17:57 <gynter> why it's not recommended?
13:18:33 <Eddi|zuHause> gynter: it may have bad side effects
13:18:36 <Rubidium> imagine the maglev changing in a steam train that's not able to run on maglev tracks
13:18:39 <planetmaker> <Ammler> there was no stable opengfx yet at all <-- I'd call 0.2.x 'stable' :-)
13:20:07 <Rubidium> or your sand quarry giving invalid cargo and looking like a part of a coal mine
13:20:28 <Ammler> I call 0.2 complete :-)
13:20:51 <Eddi|zuHause> hm... if anyone of you expected a delivery of ~2kg uranium from moldova, that shipment likely won't arrive...
13:20:55 <Rubidium> or a 1x1 becoming one tile of a 2x2 house, but the other parts not built at the right place
13:21:07 <Ammler> VVG: I just meant, contributions are still welcome :-P
13:22:29 <VVG> Ammler: i have nothing i could contribue to opengfx
13:22:32 *** valhallasw has joined #openttd
13:22:36 <Rubidium> Ammler: under those premises OpenTTD isn't stable either
13:23:15 <VVG> but it has been complete :)
13:23:41 <Ammler> opengfx should at least have no bugs, so yes, it is stable
13:24:14 <Ammler> but it might have a lot glitches :-)
13:30:55 <planetmaker> <VVG> but it has been complete :) <-- yes and no. It has no black boxes anymore
13:31:20 <planetmaker> But it has not yet fulfilled its mission: replace all original sprites by a unique sprite :-)
13:32:17 <Rubidium> even so, one could argue whether OpenGFX can ever be complete up to the moment OpenTTD dies a silent death (no more sprites needed from OpenTTD's point of view)
13:32:21 <VVG> planetmaker: that was reffering to ottd
13:32:37 <planetmaker> Though I'd rephrase the mission as "provide the graphics which make the best vanilla experience possible"
13:33:02 <Rubidium> s/vanilla/out of the box/
13:33:21 <planetmaker> It's not written yet anywhere. But I should ;-)
13:34:20 <peter1138> hurr, rpcemu's source code mentions openttd
13:35:24 *** devilsadvocate has quit IRC
13:35:46 *** Timmaexx has joined #openttd
13:38:29 <Belugas> can i have moka out of the box instead? not much a vanilla guy...
13:39:29 <Rubidium> peter1138: where? In its OSX specific code or something?
13:40:38 <planetmaker> hm... dictionaries know neither "out of the box" nor "vanilla". But "no-frills"
13:44:22 <Rubidium> peter1138: given commits like "Allow networking to be enabled on Mac OS X if built with the Cocoa GUI" I'd assume they've got some OS X specific code
13:44:32 <VVG> planetmaker: google's define knows
13:44:46 *** devilsadvocate has joined #openttd
13:45:05 <planetmaker> yeah. As does wiki
13:45:19 <peter1138> nah, it's in the ARM emulator code, talking about a performance increase
13:45:42 <peter1138> can't get it to see sample.cat :(
13:48:29 *** ChanServ sets mode: +v tokai
13:49:25 <Rubidium> any idea whether it's trivial to spawn a few jobs from bash and wait for them to be done without looping over ps output and such?
13:49:45 <gynter> how can I make "restart" to restart my scenario what I specified with -g flag?
13:50:14 <peter1138> something using fg?
13:50:21 <dihedral> alias restart "load %A"
13:50:43 <peter1138> working something like a pthread_create/pthread_join model
13:50:55 <dihedral> unless of course it's not possible to create aliases for existing commands :-P
13:51:26 <dihedral> Rubidium, map rotation list ^^
13:51:50 <peter1138> Rubidium, their OSX build uses allegro
13:52:03 <peter1138> (as does linux & windows)
13:53:19 *** devilsadvocate has quit IRC
13:55:45 <gynter> why my server starts with one premade company called Unnamed?
13:55:53 <Rubidium> hmm, fg/bg don't seem to work from a script
13:56:13 <Rubidium> gynter: because there's a company without name in the scenario
13:57:10 <gynter> is there a way to remove it?
13:59:00 <avdg> hmm… seems there is a patch for bug 4070
14:03:16 <Eddi|zuHause> Rubidium: something like "command && good_beep || bad_beep;"?
14:03:50 * Rubidium wonders whether the server has beeps
14:04:12 <Eddi|zuHause> well, replace beep by sendmail or something ;)
14:04:43 <Rubidium> and then count the numbers of emails to determine whether to progress with a script?
14:05:58 <Rubidium> do some general stuff; for (xyz) { do real time expensive operation independent of others }; do some general other stuff
14:06:19 <avdg> I probably did something wrong
14:06:22 <Rubidium> now that loop I want to "multithread"
14:06:57 <Rubidium> but I need to wait till all "threads" are finished like pthread_create + pthread_join
14:07:16 <Rubidium> though I think I've found the solution
14:07:56 <Eddi|zuHause> i'm fairly sure there are ways to do that
14:08:44 <Eddi|zuHause> i don't find one off the top of my head, though
14:09:26 <Rubidium> bah... looper isn't an option as it doesn't allow different rsync commands... unless... lets test something
14:28:04 *** Gremnon has joined #openttd
14:28:09 <Rubidium> maybe, though I've found some other solution already
14:28:23 *** Sacro2 is now known as Sacro
14:33:36 <avdg> there are still bugs with the openttd windows here, but I have no time for fixing them now
14:33:51 <avdg> or tracing the error to say it in better words
14:34:20 <planetmaker> avdg, the minimum size error hasn't been fixed
14:34:53 <planetmaker> when the main window is larger than 64^2?
14:37:47 <avdg> its something about moving when the size of openttd's window is smaller then the openttd window itsself
14:38:11 <avdg> I though someone had a segfault before, right?
14:40:46 <avdg> well I just put the report files online
14:44:54 * Rubidium wonders when we'll get reports about OpenTTD's days being too long
14:48:49 <Rubidium> as as far as I can recall ticks take 27 ms in TTD(P), but 30 in OpenTTD
14:50:12 <Eddi|zuHause> Rubidium: but that has been like this for over 5 years, and nobody reported it?
14:50:21 *** HerzogDeXtEr1 has joined #openttd
14:50:37 <Rubidium> yep, only that OpenTTD runs too fast
14:50:59 <peter1138> wtih 27ms per tick, game days are 1998ms
14:51:30 <peter1138> i surmise that ticks are meant to be 27.027ms ;)
14:52:41 <Gremnon> what're grfcodec and nforenum coded in? C?
14:52:50 <Eddi|zuHause> didn't someone wonder about the significance of 74 recently?
14:53:10 <Gremnon> now for the next one... is there an svn or similar accessible repo for each/either
14:53:42 <Eddi|zuHause> i think they are on coop devzone
14:53:58 <Gremnon> ah good, I know where to search now then
14:54:02 <Gremnon> I didn't think to check there
14:54:02 <planetmaker> did you even look?
14:54:06 <Rubidium> Gremnon: have you read the posts on the forum about nforenum/grfcodec?
14:54:08 <planetmaker> it's the 2nd hit on google
14:54:11 <Gremnon> no, actually, I haven't
14:54:21 <planetmaker> the 1st is the old one
14:54:22 <Gremnon> read the posts, that is
14:54:33 <Gremnon> I kinda forgot about them
14:54:48 <Rubidium> have you read (trunk's) readme.txt?
14:55:05 <Gremnon> .... people read files named readme?
14:55:29 <planetmaker> hm. who is minime?
14:55:31 <Rubidium> no, but we use them to point people to them under the pretense that they should have read them
14:55:50 <Rubidium> planetmaker: TTDP dev
14:56:22 <Gremnon> found them now, now maybe I'll see if my new attempt to figure out the mysterious world of NFO actually works
14:56:32 <Rubidium> planetmaker: also known for his work on tools such as GRFCodec and NFORenum
14:57:06 <planetmaker> I assume so. I just found the name as developer with access to both repos.
14:57:18 <planetmaker> so he worked on it before then
14:57:54 <Rubidium> planetmaker: also known as Dan Masek (see nforenum -h)
14:58:35 <Rubidium> planetmaker: yes, he worked on them before and asked for an account just before he went on vacation, so I hope to see him entering the IRC channel when he returns
15:02:33 <Gremnon> okay, last question for the moment... both grfcodec and nforenum should compile and run okay on 64 bit gnu-linux, right?
15:03:19 <planetmaker> binaries for both are also readily available
15:03:41 <Gremnon> that wouldn't work for what I'm attempting next, since my NFO attempt, predictably, failed
15:03:57 <Gremnon> I'm making a PKGBUILD for each for Arch's AUR
15:04:09 <Gremnon> there's ones for OpenTTD, OpenGFX, SFX and MSX, but not one for either
15:04:17 <Gremnon> so I thought I'd be the kind soul to give them
15:07:50 * andythenorth considers patching temperate so towns need food
15:08:14 <Gremnon> afaik, if an industry set defines it, they accept it
15:08:27 <Gremnon> unless you mean the same behaviour as above-snowline arctic towns
15:08:29 <andythenorth> I patched Tropic so all towns need food and water whether desert or not. But hauling water around is dull :P
15:08:33 <planetmaker> andythenorth, rather... add a newgrf feature: town growth cargo(s) configurable
15:08:39 <planetmaker> Gremnon, not really
15:08:40 <andythenorth> planetmaker: that I can't do
15:08:47 <planetmaker> andythenorth, yes, yet
15:08:57 <planetmaker> That's why I said: patch OpenTTD so that it becomes possible
15:08:59 <andythenorth> changing the string from Arctic to Temperate I can do
15:09:06 <planetmaker> Then it'd be a good patch instead of a hack ;-)
15:09:16 <andythenorth> no, my thinking is all wrong for writing real code
15:09:32 <andythenorth> I'll just end up wasting other people's time with stupid questions
15:09:34 <Gremnon> I seem to recall hearing something about a patch that turned toyland climate into a mix of temperate, tropic and arctic climates
15:09:46 <andythenorth> all climates in one?
15:09:50 <andythenorth> search the forum for it :P
15:10:18 <andythenorth> planetmaker: last time I tried to patch (for industry separation) it took me three days, and it was mostly 'code written by other people and sent to me on irc'
15:10:19 <Gremnon> I'm waiting for the search to load as I type
15:10:20 <planetmaker> sounds like suggestion forum stuff
15:10:32 <planetmaker> haha @ andythenorth :-)
15:11:01 <andythenorth> writing a spec for newgrf town growth we *could* do
15:11:35 <Eddi|zuHause> Gremnon: i don't recall anything useful ever comming out of that patch attempt
15:12:06 <Gremnon> that's a shame, it'd be interesting to have all three in one, and replacing toyland... which no one really plays on AFAIK anyway
15:12:42 <Rubidium> Gremnon: then you haven't played much on OpenTTDcoop's stable server
15:13:00 <Gremnon> I haven't played OTTDcoop at all
15:13:09 <Gremnon> I don't have a reliable enough connection for it
15:13:24 <planetmaker> hm... indeed we should offer again a toyland one there :-)
15:13:51 <planetmaker> Rubidium, but we don't have a all-climates-in-one either ;-)
15:14:23 <Rubidium> Gremnon: if you're adding nforenum and grfcodec, please add catcodec as well. Then they won't have much reasons anymore to just compile opengfx/opensfx instead of taking the binary packages
15:15:40 <Gremnon> ah, that's useful too. I'm going to see if I can make a functional grfcodec PKGBUILD first though - I've never tried making something for the AUR before, so I don't want to try three, then find the all don't work
15:16:56 <Belugas> all climates in one...
15:16:58 <Gremnon> checked out the source, ran make, all fine - but for it to be in a PKGBUILD, AFAIK it needs to work with 'make install' too
15:17:02 <Rubidium> for AUR you're probably better of using the "stable" releases of grfcodec and nforenum
15:17:05 <Belugas> it surely sounds appealing
15:17:21 <planetmaker> Belugas, sure :-)
15:17:36 <Gremnon> some packages have stables and development ones in there, the devel ones with -hg or similar on
15:17:41 <planetmaker> It would need a few more bits, though
15:18:14 <Gremnon> I also figure that the devel ones might be more worth putting there, since then one just needs to rebuild the package, and the user would have access to any newer callbacks, etc
15:19:03 <Gremnon> let me see if I can make a working PKGBUILD for grfcodec-hg first though, then I'll work from there
15:21:46 <Belugas> a few, indeed, and quite a lot of work...
15:26:52 <planetmaker> if one consideres the accessed bits without meaning for houses
15:28:01 <Rubidium> planetmaker: sufficient for what?
15:29:51 <planetmaker> 3 bits for climate info
15:30:08 <planetmaker> though one can do with two
15:30:31 <planetmaker> tropical zone info is free. So that can be thrown into the pool as well
15:30:44 <planetmaker> 'free' as in works towards similar things
15:30:46 <Rubidium> do towns have those bits?
15:30:49 <planetmaker> and could be unified with it
15:31:18 <Rubidium> hmm, guess so as it's an all climate set of bits
15:31:22 <planetmaker> houses have three bits marked as "accessed but no real meaning"
15:31:33 <planetmaker> yes, they should have that
15:31:40 <planetmaker> the tile reverts after a house is deleted
15:32:13 <planetmaker> and houses can access it ;-)
15:32:50 <planetmaker> hm. no. no access to tropical zone
15:33:25 <Rubidium> 3 bits should be enough though; snow, arctic, temperate, tropic, rainforest, desert
15:33:27 * Belugas looks at his mental plan of regions...
15:33:27 <planetmaker> Rubidium, well, houses know their height and snowyness obviously works
15:33:55 <Belugas> planetmaker, not entirely true. it's a matter of houses id and snow level
15:33:57 <Rubidium> so you'd need only 1 bit there
15:33:58 <planetmaker> Rubidium, how does that work with varying snowline?
15:34:19 <planetmaker> snow yes/no needs somewhat its own bit
15:34:27 <Gremnon> and what would happen at the tiles where snow and desert meet, if that's allowed?
15:34:51 <Gremnon> plus you'd need unified grass styles - temperate and arctic to snow are alright, but tropic to snow, and temp/arc to desert aren't
15:35:22 <Rubidium> planetmaker: arctic gets snowy or not. Don't think deserts or rainforest should become snowy at any point
15:35:35 <Rubidium> I even doubt whether temperate should get snowy
15:35:37 <planetmaker> temperate might get snow
15:35:52 <planetmaker> but that's an option for sure
15:36:00 *** Brianetta has joined #openttd
15:36:03 <Rubidium> although you could implement that as well, but then you've got snow right up to the desert/tropics
15:36:28 <Belugas> which is possible. realistic
15:36:28 <planetmaker> yes. One might introduce two snow heights: arctic + temperate
15:37:11 <Rubidium> planetmaker: that'd look possibly odd at the transition from arctic to temperate
15:37:32 <planetmaker> :-) as would the transition desert / temperate look odd
15:37:47 <planetmaker> or arctic/temperate with no snow in temperate without two snow lines
15:38:26 <planetmaker> So does it need 'transition' tiles?
15:42:23 <andythenorth> kilimanjaro is snowy :)
15:43:36 <Eddi|zuHause> about as long as the aral sea has water in it ;)
15:43:46 *** roboboy has joined #openttd
15:43:58 <andythenorth> all climates in one is a nice project :)
15:44:07 <andythenorth> might put an end to TTD original base set though :(
15:44:16 <Eddi|zuHause> andythenorth: i wouldn't hold my breath for it
15:48:08 <roboboy> hm my "mousewheel" doesn't work anymore
15:48:26 <Gremnon> the grfcodec-hg PKGBUILD is now in the AUR for arch. it works for me, but 'works for me' and 'works for everyone else' are two different things
15:48:31 <Gremnon> next up is the NFOrenum package
15:54:57 *** orudge` has joined #openttd
15:54:57 *** ChanServ sets mode: +o orudge`
15:56:03 <Ammler> I would link to without "repository"
15:56:24 <Ammler> someone could think that is the url fro clone
15:56:35 <Gremnon> oops, didn't notice that
15:56:45 <Gremnon> I'll update that now, and give NFOrenum a better description too
15:57:06 * roboboy wonders if he should reboot again
15:57:56 <Ammler> Gremnon: wouldn't it be better to use nightlies?
15:58:36 <Gremnon> I do. these packages, in theory, fetch the head revision and compile it
15:59:03 <Gremnon> my reason being that, this way one only has to recompile the package to get the latest updates to each, and therefore access to new callbacks etc
15:59:06 <Rubidium> and they won't compile when someone doesn't have a recent boost
15:59:39 <Gremnon> for those using automated AUR tools, I can just bump the package version periodically, forcing an update
15:59:52 <Gremnon> those who do it manually should know to periodically recompile anyway
16:00:01 <Ammler> Rubidium: does it check for boost version?
16:00:27 <Rubidium> if it's GCC during compilation, then yes it does!
16:00:43 <Gremnon> ah, didn't realise it required boost, I'll add it as dependency
16:01:06 <Gremnon> specific or that or later?
16:01:11 <Rubidium> oh, you mean Gremmon's pkgbuilds? No, they don't specify a boost version... they don't specify it requires boost at all
16:01:18 <Gremnon> yes, I'm about to update that
16:01:46 <Rubidium> Gremnon: somewhere from boost 1.40-ish it works (not sure which exactly)
16:01:53 <Ammler> grfcodec works with every boost
16:02:01 <Ammler> nforenum needs a very recent version
16:02:31 <Gremnon> the boost from the arch repositories is 1.43, so unless it needs a newer version, I'll leave both without a specific version check and specify just boost
16:02:57 <Ammler> doesn't arch have different releases?
16:03:25 <Gremnon> no, it's a rolling release
16:03:49 <Gremnon> Rubidium, I'll leave it without for now unless anyone else has trouble with it
16:05:08 <Gremnon> packages updated. same link as before for each
16:05:59 <Gremnon> I updated the descriptions for each with the ones on the overview page
16:06:46 <Gremnon> catcodec might take a little longer unless someone cares to help me add a 'make install' to it
16:06:59 <planetmaker> <Ammler> min. 1.41 afaik <-- 1.40 works, too
16:07:18 *** fmauneko has joined #openttd
16:08:37 <Eddi|zuHause> i needed to upgrade boost at least twice to compile renum in the past
16:09:45 <Eddi|zuHause> Gremnon: it might be useful to specify a version anyway, in case someone has not updated yet, or you need an updated boost in the future
16:10:36 <Gremnon> right, time to figure out how to specify a version then
16:13:42 <welshdragon> OSX 10.5 won't run 2 instances of OpenTTD
16:14:07 *** ChanServ sets mode: +o orudge
16:15:07 <planetmaker> welshdragon, then it must be different from 10.4 and 10.6
16:15:15 <planetmaker> or you do something different ;-)
16:15:48 <planetmaker> you started it from the command line?
16:16:14 <welshdragon> planetmaker, ooh, no
16:16:21 <welshdragon> from the launcher
16:17:31 <welshdragon> er, how do i start it in the command line?
16:18:32 <Gremnon> packages updated again. They now specify boost 1.43 or higher
16:20:05 *** Born_Acorn has joined #openttd
16:26:39 <CIA-2> OpenTTD: rubidium * r20613 /extra/catcodec/ (Makefile Makefile.bundle): [catcodec] -Change: make install and unify output
16:27:37 <Gremnon> one catcodec package coming right up
16:36:35 <Gremnon> should work safely, unless there's a dependency that isn't mentioned
16:39:28 <CIA-2> OpenTTD: rubidium * r20614 /extra/catcodec/ (27 files in 3 dirs): [catcodec] -Change: make the layout look more like GRFCodec and NFORenum's layout; installation and such works in a similar way as well
16:40:51 <roboboy> does catcodec only produce sample.cat like .cats, or could it theoretically be used for creating .cats that contain the DOS music if it's format is ever cracked?
16:42:09 <Rubidium> it only supports the sample like cats
16:42:12 <Noldo> ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
16:42:40 <Rubidium> and actually, I don't think it writes TTDP acceptable cats
16:43:23 * roboboy tries the OpenSFX .cat in TTDP
16:45:45 <CIA-2> OpenTTD: rubidium * r20615 /extra/catcodec/ (Makefile.bundle changelog.txt findversion.sh): [catcodec] -Add: a changelog
16:46:40 <roboboy> what's special about catcodec cats?
16:47:01 <Gremnon> perhaps a better question would be what's special about TTD(P) cats
16:47:50 <roboboy> or from what ive read catcodec produces special cats so hacks in OpenTTD work
16:48:15 <planetmaker> roboboy, it has a slightly different internal format
16:48:19 <Ammler> it is better quality afaik
16:49:00 <planetmaker> And OpenTTD somehow knows how to distinguish old and new cat format
16:49:30 <Rubidium> Gremnon: besides that TTD(P) cats say they have samples played at X Hz with Y bits per sample when that information is ignored and always 11025Hz 8bps is used?
16:49:54 <Rubidium> and the "corrupt" sound that doesn't even have a proper WAV header?
16:50:46 <Rubidium> over the "new" cat format that always has a proper WAV header and where OpenTTD obeys the X Hz and Y bits per sample in the .cat instead of overriding it itself
16:52:05 <Rubidium> and as a side effect OpenSFX's samples have higher Hz and higher bps, so basically (potentially) higher quality
16:53:46 <Gremnon> so no way to add TTDP compatibility then
16:54:13 <planetmaker> oh, you could write a converter ;-)
16:54:44 <Rubidium> planetmaker: you mean one that downsamples the songs and removes the WAV header from the Nth song?
16:55:10 <planetmaker> Rubidium, exactly ;-)
16:55:13 <Rubidium> roboboy: yes, but decode original sample.cat + encode that != original sample.cat. For OpenSFX it should hold though
16:55:55 <roboboy> so I could try and decode OpenSFX.cat and recode it with decat
16:56:25 <Gremnon> theory - is it possible to have a parameter to pass to the encoder part of catcodec that would attempt to make it a TTDP compatible cat, or would that not work?
16:57:28 <planetmaker> roboboy, does "decat" allow re-encoding?
16:58:11 <planetmaker> description only talks about decoding ;-)
16:59:49 <roboboy> I think I read about a tool or I could try and write myself one if I was so inclined
17:01:33 <roboboy> well gmorning as I need to go to sleep
17:02:32 <Rubidium> ofcourse it's possible to add such a parameter, but I'm never going to do that as it's simply too much work for way too little benefit
17:02:58 <Gremnon> I wasn't implying it should be added, just wanted to know if it could be aded
17:04:06 <Rubidium> it "just" requires downsampling the WAVs and not putting the WAV header of one of the files in
17:04:15 *** frosch123 has joined #openttd
17:05:28 <Gremnon> now I see just how much for too little
17:11:06 * Gremnon bites the hand that pets him
17:11:54 <Gremnon> I'm just a wolf in very heavy disguies as a duck
17:12:40 <CIA-2> OpenTTD: glx * r20616 /trunk/projects/ (6 files): -Change: disable .sbr/.bsc generation in MSVC project files
17:12:49 <Gremnon> you just need to have your eyes tested if you can't tell the difference
17:12:56 <Gremnon> the other ducks don't seem to have noticed
17:16:27 <frosch123> frogs have teeth, just ask Grover
17:19:21 <yorick> dihedral: not currently
17:19:40 <dihedral> ok, thanks for the feedback :-)
17:36:01 *** jonty-comp has joined #openttd
17:42:10 <VVG> There is a "default station" list item, which i can't select at all. In this game, i did add some station grf midgame.
17:43:15 <dihedral> adding grf in the middle of the game is not supported as far as i know
17:44:11 <Gremnon> by the image, that's MB's newstations... which I recall sometimes does that even before the game, there's a 'default station' tile at the end of the list for me, also unselectable
17:44:24 <Gremnon> I think it might be caused by loading multiple station grfs, but not certain
17:44:47 <planetmaker> VVG, if you load too many station sets, the default station category gets flooded with the excess stations
17:44:59 <planetmaker> Except if you have a very recent nightly
17:45:07 <Gremnon> or Chillcore's patchpack
17:45:13 <VVG> i have a bunch of them, preloaded from start, later midgame i noticed i lack void platforms, so i added them
17:45:31 <Gremnon> but this isn't the default station category getting flooded, this is the default station from the default station category appearing where it shouldn't
17:45:41 <Gremnon> as well as where it should
17:45:44 <CIA-2> OpenTTD: translators * r20617 /trunk/src/lang/ (9 files): (log message trimmed)
17:45:44 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:44 <CIA-2> OpenTTD: belarusian - 2 changes by KorneySan, Wowanxm
17:45:44 <CIA-2> OpenTTD: finnish - 2 changes by jpx_
17:45:44 <CIA-2> OpenTTD: german - 2 changes by planetmaker
17:45:46 <CIA-2> OpenTTD: greek - 2 changes by fumantsu
17:45:46 <CIA-2> OpenTTD: hungarian - 1 changes by IPG
17:45:53 <VVG> thing is, it's not that it is flooded
17:46:01 <VVG> it's an item, that can't be selected
17:46:17 <VVG> the selecatable defaul station item is up there in the list, working
17:47:11 <VVG> so, in the end, two defaul station items, one properly working, one just occuping a line :)
17:48:08 <VVG> does the station list has to be made before the start of the game with this "very recent nightly" or it will be ok with older save games?
17:48:19 *** devilsadvocate has joined #openttd
17:48:43 <Gremnon> AFAIK, nightlies are always backward compatible with previous nightlies and stables except in rare cases
17:50:10 <Gremnon> if you're still not sure, get a nightly, and run it separate from your current version, or keep a backup just in case
17:51:03 <VVG> but i didn't meant save game as a whole, just a station list
17:51:59 <VVG> save game was made some time ago with trunk, my custom 20612 build still have that void defaul station item if i load that save game. And while this build shouldn't have anything to do with station lists, i'm compiling clean trunk now to check it
17:52:14 <Gremnon> just done that for you
17:52:36 <Gremnon> with no other newGRFs loaded, I get 'Default Station' at the bottom of the 'Station Building (small) category
17:53:38 *** Alberth has joined #openttd
17:53:46 <Gremnon> whether it's in MB's new stations or openttd though is another matter
17:54:31 <VVG> looks like grf's fault, start new game with just mbs, there is unselectable default station item
17:54:58 <planetmaker> well. Maybe it's still that the grf is incorrectly interpreted
17:55:15 <Gremnon> it could be the way openttd handles the grf, I've known some times when it's been a bit iffy where TTDP works fine, and vice versa
17:55:39 <planetmaker> :-) that happens when there are two implementation of the same specs
17:56:11 <Gremnon> so you think it could be openttd's handling of the grf, and not the grf itself?
17:56:38 <Rubidium> well, start by running the NewGRF's nfo through nforenum
17:57:43 <VVG> except for MB's newstations, are there station grf with platforms, that look like default grass?
18:00:10 <Gremnon> nforenum throws up quite a collection of warnings... haven't looked at said warnings yet though
18:00:53 <VVG> Haha, just noticed there is Museum of moder arts building in ttrs, greatest ttd build i have seen :)
18:01:18 <Gremnon> looking at the warnings, I'm going to go with it being an issue on the grf's part
18:02:00 *** ajmiles has joined #openttd
18:09:15 *** TheMask96 has joined #openttd
18:19:02 *** |Jeroen| has joined #openttd
18:45:59 <Gremnon> I know a developer at one point said that OpenTTD wasn't going to support threading... but was any attempt ever made at it?
18:46:36 <Rubidium> yes, 5% faster on multicore, 10% slower on single core (or something like that)
18:46:57 <Rubidium> and that was *without* proper locking, so it wasn't multiplayer safe
18:47:52 <Gremnon> ah, I see... that leaves me with another question though... on win-vista on my laptop, which is dual-core, it somehow at least appears to use both cores when openttd is running
18:48:08 <Gremnon> yet while the same computer uses Arch, it doesn't do this, and I can't understand why Vista is doing it, or how
18:48:19 <Gremnon> both using clean trunk, in case it matters
18:49:10 <Rubidium> how does it appear to be using multiple cores?
18:49:43 <Rubidium> autosave definitely benefits from the second core
18:49:53 <Gremnon> I've got an applet on the vista sidebar that shows me the usage on both cores separately, with nothing else running, they both average 2% usage on each. Start OpenTTD and leave it on the title screen, and both cores go up to ~80%
18:50:06 <Gremnon> close it and they both go back down again
18:50:36 <Gremnon> at the very least, it seems to be using both, if there was less usage on one core, I'd just put it down to everything else being shifted to that core to make room for OpenTTD on the other
18:50:40 <Rubidium> might be that Windows does something fancy with its video driver
18:51:15 <Rubidium> like when OpenTTD put its graphics stuff there it'll quickly make a copy and then on the other core it actually draws it to the video card
18:51:40 <Gremnon> if both Arch and Windows are using the exact same version of their driver, shouldn't both be able to do it?
18:51:50 <Rubidium> also sound and music seem to be running in a different thread, so they could run on another core as well
18:52:12 <Rubidium> Gremnon: they can't be using the exact same version
18:52:14 <Gremnon> hmm, I see... so it could just be Windows shifting those parts that can be shifted, to the other core
18:52:31 <Gremnon> I'm fairly sure they show the same version number, that's what I meant
18:53:22 <Rubidium> maybe they have a year-month version numbering as well
18:54:07 <Gremnon> I can check it, I'd have to go reboot into Win to do so, and see if I'm right about the versions, but even then, if both are using the nvidia driver, and it's that driver doing it, shouldn't both be able to?
18:54:14 <Gremnon> unless it's Windows that's actually doing it
18:54:34 <Rubidium> the API of Linux and Windows is so different they simply can't be the same driver
18:54:45 *** Chillosophy has joined #openttd
18:54:48 <Gremnon> now I think I see another reason why multithreading isn't so simple... I'm starting to get confused
18:55:47 <Gremnon> I think I'm just going to leave it alone, maybe it won't run so well on linux, but better that, than open this can of worms, methinks
18:56:51 <Rubidium> Gremnon: did you fastforward when testing this?
18:56:57 <Rubidium> or just normal gameplay?
18:57:17 <Gremnon> just normal gameplay, I almost never use fastforward at all
18:57:18 <Rubidium> because if you didn't fast forward, then Linux is better as it's using way less CPU
18:57:44 <Rubidium> using 2 cores at 80% vs 1 core at (maybe?) 100%
18:58:15 <Gremnon> aye, I noticed that, but to get that to happen for me, I have to run it windowed at 800x600, on Windows because of whatever fancy thing it does, I can run it windows, but maximized to the available screen (which is about 1440x900)
18:59:12 <Gremnon> I don't run it proper fullscreen on either, because I usually have other stuff going, but I can definitely get it maximized with only a minimal impact on Windows
18:59:24 <Gremnon> give me a moment, and I'll give you the CPU usage on Linux
19:01:20 <Gremnon> most of the load is actually on the xorg process instead of openttd itself, confirming that the video stuff is where it's probably happening, and it uses ~85-98% of one core only
19:03:03 <CIA-2> OpenTTD: rubidium * r20618 /trunk/src/main_gui.cpp: -Fix [FS#4081]: drawing the "OpenTTD" text in the intro game caused crashes with very low resolutions
19:05:46 <CIA-2> OpenTTD: rubidium * r20619 /trunk/src/video/cocoa/ (wnd_quartz.mm wnd_quickdraw.mm): -Fix [FS#4070]: [OSX] Limit minimum window size to 64x64 like all other platforms (matheweis)
19:09:23 * Rubidium wonders when the next flame comes that I'm frustrating Mac OS X packagers
19:10:32 <Gremnon> I considered getting a mac once. It was about two days before OpenTTD stopped being officially supported for it. I stopped considering it at the same time
19:11:03 <Gremnon> If all of the OS I use can't do the same things in one way or another, I don't like it, it means rebooting from one to the other too much
19:11:49 * Rubidium doesn't have such good price-quality experience with Macs
19:12:24 <Rubidium> my brother has had 2 Macs and both had problems with some inverter or something. In any case, the (LCD) screen was flickering
19:12:26 <Gremnon> aye, I heard that about them too. like most apple things, they seem to be designed to look nice, not work well...
19:13:15 <Gremnon> once or twice I've considered creating a 'hackintosh' despite it's... dubious legality, to say the least. At least it doesn't cost, but it's always been it's legality that's put me off
19:13:21 <Rubidium> and if there's one thing I can't stand it's flickering screens. Give me a badly configured CRT and I'll be having headaches + vomit sessions for the next few hours
19:13:50 <Gremnon> which is odd, since I'll readily admit I pirate music because I'm often too skint to pay for it, and can't be bothered to make the trek into the neighbouring town just to buy an album I onlt want track from
19:13:57 <Gremnon> ah, yep, I know that one too
19:14:17 <Gremnon> try going between three screens, one at 50, one at 60 and one at 70hz
19:14:23 <Gremnon> (or whatever it is instead of hz)
19:14:31 <Gremnon> guaranteed to make you feel at least queasy
19:18:18 <Rubidium> and the cheapest Mac with my preferred (laptop) screen resolution is 2 inches bigger than the one I've got now, twice as expensive. That Mac has 200 GiB more HDD though (only using 50% of my current HDD, which has two full copies of previous installs including homedirs with openttd checkouts and such)
19:19:00 <Rubidium> (1.1 GiB for ~/.openttd, 5.5 for ~/openttd)
19:19:08 <VVG> The weight multiplier setting - does it affect all cargoes? Or are pax/mail an exception?
19:22:02 <frosch123> and yes, by default only passenger and mail are not freight
19:23:00 <VVG> Is there some special bit in newgrfs to set a particular cargo to freight/not freight?
19:23:08 <frosch123> yes, there is some property
19:24:57 <Gremnon> I manage to make do with a small 80gb hard drive when dual-booting, and I've made do with smaller before by tidying up regularly
19:25:05 <Gremnon> but to each their own
19:31:16 <planetmaker> someone really made some optimization runs it seems
19:32:19 <Gremnon> I'm just trying it out now
19:32:23 <andythenorth> Rubidium: why are you even looking at Mac prices? :P
19:32:49 <Gremnon> I thought I'd apply the first two against Chillcore's patch pack... the second doesn't apply, but the first does, so I'm trying that
19:32:52 <Rubidium> andythenorth: because I was doing a general search into 1920x1200 screen size laptops
19:33:38 <planetmaker> hm... links don't work for me :-(
19:33:52 <Gremnon> I just used the attached patches
19:34:04 <Gremnon> I didn't bother with the third
19:36:03 <Rubidium> the first mostly looks like stupid compiler... it should just fracking inline those things because we said it should do so
19:36:21 <Gremnon> apparently it doesn't then
19:39:29 * Rubidium wonders whether it actually compiles
19:39:44 <Rubidium> +if (not stationAndRadius.Intersects(location)){ <- that looks suspicious
19:40:03 <Gremnon> the first patch against chillcore's patchpack, with the matching trunk revision, compiles
19:40:10 <Gremnon> I haven't tried the first and second against trunk yet
19:40:21 <Alberth> does the new C++ standard not introduce 'and' for && etc ?
19:40:48 <dihedral> and replace ( and ) with , ?
19:41:02 <SmatZ> and or bitor bitand ... and now keywords :-p
19:41:11 <dihedral> if, not funny, go home.
19:41:35 <SmatZ> I thought you were asking
19:41:59 <Rubidium> what C++ spec does add that?
19:42:45 <Alberth> oh, perhaps it is C99
19:44:00 <Gremnon> well, they seem to have applied almost cleanly against trunk, the second one just needed to be told to apply anyway, and it worked, now to see if it compiles
19:44:39 <Alberth> SmatZ: it was both a remark and a question :)
19:48:54 <Gremnon> compiling seems to have taken considerably longer, but there are no warnings, and it's compiled sucessfuly
19:52:07 <SmatZ> $ g++-4.6.0-pre9999 tstX.c -std=c89
19:52:08 <SmatZ> cc1plus: warning: command line option "-std=c89" is valid for C/ObjC but not for C++ [enabled by default]
19:52:13 <SmatZ> now what have I broken...
19:52:23 <SmatZ> why does it think it's a C++ file?
19:53:37 <SmatZ> Alberth: anyway, gcc -std=c99 doesn't accept "bitand", but it is accepted in C++98 mode
19:53:59 <SmatZ> either gcc is wrong, or it was already part of the "old" C++ standard...
19:54:12 <Gremnon> hmm, running unmodified openttd with 'time' and a build patched with those two performance ones does seem to have made an increase, but it's negligible - left on the title screen for 30 second each, there's less than 0.2s difference
19:54:47 * Gremnon wonders if the patches are really all that useful overall
19:55:00 <Eddi|zuHause> "It might have been easier to fuly use your CPU in 1995, but then you generally wouldn't hit that limit until you're pretty far into the game anyway." <-- i first played TT on a 386DX25, and i hit the limit at about 5-10 trains. when i hit the train limit of 80 in the next 10 game years, game was hardly progressing at all...
19:55:07 <Rubidium> Gremnon: with music, video and sound enabled I reckon :)
19:55:40 <SmatZ> there is one strange thing in his benchmarking
19:55:42 <SmatZ> openttd -x -v null:ticks=10000 -s null -m null -g [SavegameName]
19:55:51 <SmatZ> he says he runs the game for 10000 ticks
19:55:54 <Gremnon> true... I'll try playing a game for a bit on the build of chillcore's pack where I added the first one in, and see if it differs
19:55:58 <SmatZ> and is finished in <2 minutes
19:55:59 <Eddi|zuHause> unfortunately, i lost that first savegame, due to the world editor overwriting it with the autosave :(
19:56:41 <Gremnon> probably not, but even so, maybe long-term usage under normal use situation will show some difference
19:56:43 <Alberth> SmatZ: I have a very thick book at work that should contain the answer. If I remember, I'll have a look.
19:57:02 <SmatZ> it that's true, then "1024x1024 map with huge cities and lots of trains:" isn't really "lots of trains"
19:57:15 <SmatZ> Alberth: thanks, it's probably not needed :)
19:59:30 <Rubidium> I count ~700 trains in that savegame
20:00:08 <Rubidium> roughly 300 stations
20:00:11 <SmatZ> or his CPU is much more powerful than mine :)
20:01:49 <Rubidium> still wonder whether he tested with or without exceptions
20:01:50 <Eddi|zuHause> that does sound like a lot ;)
20:02:08 <Eddi|zuHause> you mean asserts?
20:05:30 <Rubidium> real 2m9.767s <- that's how long 10k ticks of 1024x1024 takes for me (non debug, with asserts)
20:06:12 <Rubidium> @calc 7947339048/2830000000
20:06:12 <DorpsGek> Rubidium: 2.80824701343
20:06:41 <Gremnon> doesn't really seem like enough to make it worth it to me
20:09:25 <Rubidium> 1:58 without assertions
20:09:36 <DorpsGek> Rubidium: 0.914728682171
20:10:14 <Rubidium> so OpenTTD's 8% faster without assertions :)
20:15:56 <Rubidium> real 1m39.918s without assertions, with patch
20:16:08 <DorpsGek> Rubidium: 0.838983050847
20:16:20 <Rubidium> that's quite a serious amount
20:17:04 <SmatZ> load average: 15.75, 15.76, 12.77
20:17:15 <SmatZ> I will do some testing when the system is not under load :)
20:19:49 <dihedral> sorry - just needed some odd remark :-P
20:25:22 <Rubidium> 2048x2048 populated from 52 -> 25
20:25:56 <planetmaker> sounds like a useful patch then
20:26:39 <Rubidium> 2kx2k map with a gazillion towns and not much else
20:26:57 <planetmaker> both patches or only one?
20:28:24 *** perk111 has joined #openttd
20:28:43 <Rubidium> fewer towns: 43 -> 40
20:29:53 <Rubidium> though the latter two are more the hypothetical kind I'd say
20:31:14 <Eddi|zuHause> that's also ~10%
20:33:43 <planetmaker> psgs 101, 180 and 186 might be interesting, too
20:35:27 <planetmaker> psg #180 is 3k trains
20:35:31 <planetmaker> on a logic network
20:36:45 <Rubidium> trains won't matter that much; this primarily focusses on map accesses and cargo -> station stuff
20:37:49 <planetmaker> there we have a 200k single cargo output record ;-)
20:37:57 <SmatZ> I used to have patch that cached all stations nearby for town/industry
20:38:02 <SmatZ> but I can't find it anymore
20:38:11 <SmatZ> it would be interesting to compare those two patches
20:38:25 *** TomyLobo has joined #openttd
20:38:26 <planetmaker> oh, sorry. wrong. that's proZone game 13
20:39:21 <planetmaker> psg101 is many pax trains.
20:39:23 *** fonsinchen has joined #openttd
20:39:31 <planetmaker> in 4 towns covering the whole map.
20:39:41 <planetmaker> That will have lots of station accesses in many places
20:39:48 <planetmaker> that's little gain
20:40:04 <Eddi|zuHause> but at least no slowdown yet
20:42:46 <Eddi|zuHause> so three questions now: 1) is the implementation "correct", as in doesn't change gameplay? 2) is the style ok? 3) does this reduce maintainability or old compiler compatibility?
20:43:38 <SmatZ> Eddi|zuHause: 1) hope so :) 2) no, but it can be changed 3) in most cases, caching makes maintainability harder...
20:44:27 <Eddi|zuHause> well, 1) is also often a case of "how does it behave when someone joins the game, and the cache is not rebuilt simultaneously on the server and client?
20:44:38 <Eddi|zuHause> yapf cache had lots of problems witht hat
20:50:34 <Rubidium> PSG96 is quite slow: 3:32 (same amount of ticks over 90 and 132)
20:50:39 <Rubidium> still waiting on the patched version
20:51:56 <Rubidium> if it's a cache it shouldn't be rebuilt upon joining; it should represent the "real" state correctly, but (much) faster
20:53:58 <Eddi|zuHause> i think the problem with YAPF cache was that it depended on the order of things being added
20:54:18 <Rubidium> oh... 3:33 for the patched version
20:54:39 <Eddi|zuHause> so the state differed between a slowly builtup cache, and a rebuilt cache
20:57:20 <Rubidium> now it's 1:06 vs 1:04
20:57:40 <planetmaker> uh? cache vs. not cache?
20:57:41 <Eddi|zuHause> i'd put that off as statistical variaton...
20:58:00 <Rubidium> planetmaker: unpatched vs patched
20:58:15 <planetmaker> yes but compared to 3:33 before?
20:58:48 <planetmaker> or 'just' another game?
20:59:01 <Rubidium> same game, 70% less ticks
20:59:46 <planetmaker> hm, psg#96 has many stations in many places indeed
20:59:52 <Eddi|zuHause> sounds like most of the time is spent in other parts of the code
20:59:57 <planetmaker> but the map is not really big
21:00:11 <Eddi|zuHause> like, pathfinder or acceleration
21:00:14 <planetmaker> Eddi|zuHause: that game has somewhat a grid of stations
21:00:24 <planetmaker> three big towns, each with a local network
21:00:34 <planetmaker> ice running between those towns' central stations
21:00:52 *** TruePikachu has joined #openttd
21:00:59 <planetmaker> acceleration will matter there, sure
21:01:43 <Eddi|zuHause> if path_backoff_intervall [or so] is low, a deadlock can kill the game
21:02:02 <Rubidium> Eddi|zuHause: true, though I'd expect a slightly bigger different; it's all 1 or 2 seconds in these (NewGRF) PSG savegames
21:02:14 <Rubidium> agains 4 seconds for a pre NewGRF PS savegame
21:02:19 <planetmaker> that is usually set to 1
21:02:36 <Eddi|zuHause> isn't the default like 30 or so?
21:02:50 <planetmaker> (the back-off interval) Yes, usually it's much higher
21:02:57 <Ammler> the logic excess is the only game, we found effect on changing that :-)
21:03:06 <planetmaker> or maybe it's 0. We don't want trains to turn
21:03:18 <Eddi|zuHause> that's a different setting
21:03:34 <Eddi|zuHause> backoff_interval is for retrying to reserve a path, when reserving a path failed
21:04:27 <planetmaker> and I recalled correctly the setting but not its meaning ;-)
21:05:35 <Eddi|zuHause> i rembember the old PBS... i had ~100 trains, and every time a deadlock occured on a part of the network, the game got notably slower
21:06:47 <Eddi|zuHause> that was before a yapf-compatible pbs version appeared
21:06:57 <planetmaker> yes. But jams are more likely also, if trains slow down due to not having yet reserved a path :-)
21:07:03 <planetmaker> That's why we set it to a low value
21:07:28 <planetmaker> For heavy-duty lines the default value is a notable slow-down
21:08:06 <planetmaker> But by default we don't use much path signals
21:08:15 <planetmaker> only in some junctions and station entries
21:08:29 <planetmaker> so it's not a big issue on the PublicServer
21:09:02 <Eddi|zuHause> "a lot of" ... saves most of the trouble ;)
21:09:50 *** Brianetta has joined #openttd
21:16:23 * andythenorth likes the 'found a town' feature :)
21:16:43 <TruePikachu> How does it work? I've never used it
21:17:00 <andythenorth> I don't know yet, I don't have enough money :(
21:17:02 * TruePikachu has never had enough money and the need to use it at the same time :(
21:17:22 <andythenorth> it would be nice if the game would occasionally found a town
21:17:33 <andythenorth> specifically, if it seeded them near busy transfer stations
21:17:37 <TruePikachu> I am especially interested in the 'custom layout' option; I'll look at source to try to decypher the operation
21:17:52 <TruePikachu> andythenorth: It would overflow eventually then
21:18:07 <andythenorth> I want all my grain elevator stations to get a little 2 horse town next to them :P
21:18:20 <TruePikachu> That's why you can found towns
21:18:30 <planetmaker> ;-) yet another adv. setting
21:19:00 * TruePikachu is also glad that Rubidium is getting along with me - FS#4080
21:19:30 <andythenorth> is there a good AI for running simple bus routes? I can't be bothered
21:19:42 <andythenorth> I need to grow towns...
21:20:43 * TruePikachu just accidentially discovered ^A in vim
21:20:54 <Ammler> I guess, I never played with AIs since noai is in trunk :-)
21:21:02 <TruePikachu> andythenorth: SimpleAI, but it is an idiot and does more than that
21:21:21 <planetmaker> both will spam you with bus routes
21:23:06 *** Brianetta has joined #openttd
21:24:30 <TruePikachu> According to file "town_gui.cpp" lines 1046-1051, when founding a town, you can select size, layout (grid style), if it is a city, etc. just like in scenerio editor - I am not sure if this is the same window as called in-game
21:25:54 <TruePikachu> ShowFoundTownWindow() says it is the same window, though
21:26:11 <Rubidium> VVG: I doubt the TTU_HHMMSS rounding factor is right
21:27:09 <Rubidium> and N seconds are one tick, time_taken is in ticks, so if N = 4, you'd round to the nearest 16 seconds
21:27:23 <Rubidium> instead of the nearest 4 seconds
21:29:52 <TruePikachu> Are lines 256 and 257 in osk_gui.cpp fully customizable to no ill effects?
21:30:32 <TruePikachu> I may have to adjust it to help with the OttdKiosk project
21:32:42 <TruePikachu> Umm...never mind, won't adjust height, which is also important :(
21:32:53 *** wollollo has joined #openttd
21:37:31 <VVG> Rubidium: So, i can just use 1 for HHMMSS case and just let the gui time conversion do its job?
21:38:33 <Rubidium> yes; ticks aren't fractions
21:39:07 <TruePikachu> Would it ever be possible to have multiple airports allocated to the same station?
21:40:46 <VVG> may be it's better to use rounding only in case of days or HHMM? and just time_taken = time_taken if it's ticks or seconds?
21:43:05 <Rubidium> basically you've got second < tick < minute < day
21:43:45 <Eddi|zuHause> TruePikachu: it's not beyond technical practicability, but i have seen no attempts to implement that
21:43:54 <Rubidium> or in numbers, when N = vsec: 1/N < 1 < 60/N < 74
21:44:55 <TruePikachu> Hmmm...I'll put it into the FS
21:47:06 <VVG> what will be the result of 1/N in case of ints?
21:50:14 <Rubidium> but anyhow, if you have N=4 and 12:00:00, then there won't be a 12:00:01,02,03. The next will be 12:00:04
21:52:21 <VVG> from game playing point of view, 1tick=4 sec doesn't seem feasable, it goes by too fast
21:57:17 <Eddi|zuHause> i always had 1tick=1second, but on small maps, that might be a different thing
21:57:22 <VVG> btw, from ottd coding style point of view, is using enum TTU_DAYS-TTU_HHMMS a good thing?
21:59:09 <Eddi|zuHause> what do you mean? like grouping several related constants into an enum?
22:01:11 <VVG> enum TimetableUnit with those values is the only one enum in settings_type.h. It does makes reading code much easier for me. But i wondered, if it is proper to use such enum just for making reading the code easier? It is possible to use some comment in the code where switch is used
22:07:17 <VVG> in other words, adding simple comment in the code renders this enum useless
22:07:47 * TruePikachu will play a game from 1830 to 2050
22:09:03 <TruePikachu> 1 tick is hardcoded as 30ms, correct?
22:09:51 *** Phoenix_the_II has quit IRC
22:09:52 <Rubidium> enums are better than comments for e.g. switch statements because the compiler is basically "spellchecking" whether you've written it the same everywhere
22:10:22 <Rubidium> whereas with comments you can much more easily make typos and as such you might not be able to find stuff back again
22:10:49 <Rubidium> likewise when it is an enum it's easier to rename or change the value
22:11:02 <TruePikachu> My game will take at least 49 hours 33 minuts 4.29 seconds O_o
22:11:24 <VVG> kinda got it, enum in this case is a good thing :)
22:17:50 *** [hta]specx has joined #openttd
22:19:28 <TruePikachu> Lol, no trains yet here in 1830
22:20:10 <TruePikachu> I will do intra-city operations until the trains are availible
22:20:34 <TruePikachu> Should take up to 18 months
22:34:45 *** last_evolution has joined #openttd
22:36:19 *** Xrufuian has joined #openttd
22:36:41 *** Sacro1 is now known as Sacro
22:43:10 <TruePikachu> Xrufuian: I can't do multiplayer right now; I'm doing a week-long game I just started
22:43:32 <Xrufuian> Who says I came here for that?
22:43:55 <TruePikachu> Well, I'm short $1k for the first year in running cost
22:52:44 <Eddi|zuHause> you don't talk about it?
22:56:03 <Xrufuian> Right, my number one rule: Don't assume anything.
23:24:34 <TruePikachu> Lol, 2 years in, and I have 75 RVs
23:26:13 <Eddi|zuHause> and you think that's an achievement?
23:26:46 <Eddi|zuHause> that's like two cities worth of tram networks...
23:28:33 *** Wizzleby has joined #openttd
23:46:16 * avdg is happy with the fixes :)
23:46:37 <avdg> seems a lot was happening when I was gone
23:55:36 <Eddi|zuHause> it's weird... whenever i skim the graphics development forum, the title "[TTDX] NewObjects GRF Coding Guide * UPDATE" triggers my brain heuristics for detecting SQL statements ;)
23:55:37 *** last_evolution has quit IRC
23:57:56 <avdg> +1 for UPDATE keyword :)
23:59:24 <Eddi|zuHause> yes, plus the "*" and uppercase text mixed with not-uppercase text
continue to next day ⏵