Config
Log for #openttd on 19th August 2010:
Times are UTC Toggle Colours
00:00:53  *** DarkNemesis [~sara@09GAADDT3.tor-irc.dnsbl.oftc.net] has quit [Quit: Ex-Chat]
00:05:39  *** KenjiE20 [~KenjiE20@92.19.165.204] has quit [Quit: WeeChat 0.3.3]
00:18:27  *** bryjen [~bryjen@75.81.201.131] has joined #openttd
00:22:00  *** nicfer [~nicfer@190.50.12.214] has quit [Remote host closed the connection]
00:22:13  *** nicfer [~nicfer@190.50.12.214] has joined #openttd
00:31:48  *** JVassie_ [~James@92.27.149.231] has quit [Ping timeout: 480 seconds]
00:32:36  <Eddi|zuHause> "Andere Leute wÃŒrden solch Set erst in 10 Jahren der Öffentlichkeit vorstellen und vorher gelegentlich Screenshots posten." <-- lmao ;)
00:34:59  <Rubidium> smells like someone making a joke of mb
00:39:15  *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has quit [Ping timeout: 480 seconds]
01:10:45  *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Quit: Leaving.]
01:22:30  *** fmauneko_ [~fmauneko@134.227.101-84.rev.gaoland.net] has joined #openttd
01:24:16  *** fmauneko [~fmauneko@237.54.71-86.rev.gaoland.net] has quit [Ping timeout: 480 seconds]
01:28:35  *** fmauneko_ is now known as fmauNeko
01:36:59  *** bryjen [~bryjen@75.81.201.131] has quit [Quit: Leaving]
01:50:13  *** fmauNeko [~fmauneko@134.227.101-84.rev.gaoland.net] has quit [Ping timeout: 480 seconds]
01:52:31  *** murr4y [~murray@169.84-49-70.nextgentel.com] has quit [Ping timeout: 480 seconds]
01:54:39  *** nicfer [~nicfer@190.50.12.214] has left #openttd []
01:54:54  *** llugo [~lugo@mgdb-4db8ca40.pool.mediaWays.net] has quit [Remote host closed the connection]
02:04:01  *** murr4y [~murray@169.84-49-70.nextgentel.com] has joined #openttd
02:06:50  *** Eddi|zuHause2 [~johekr@p54B779BA.dip.t-dialin.net] has joined #openttd
02:08:55  *** glx [glx@2a01:e35:2f59:c7c0:ad04:2178:e4c8:4b52] has quit [Quit: bye]
02:13:05  *** Eddi|zuHause [~johekr@p54B779BA.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
02:14:13  *** Fuco [~dota.keys@188.123.106.105] has quit [Ping timeout: 480 seconds]
02:18:38  *** DDR [~chatzilla@66.183.117.37] has joined #openttd
02:19:05  *** donoteat [~chatzilla@ip68-100-180-162.dc.dc.cox.net] has joined #openttd
02:19:44  <donoteat> is there a way to get a scenario made in Chill's patchpack version of OTTD to work in the trunk version of OTTD?
02:19:56  <donoteat> or do I have to start everything over again?
02:20:49  *** rhaeder1 [~quix0r@dslb-094-221-151-171.pools.arcor-ip.net] has quit [Remote host closed the connection]
02:22:46  *** rhaeder [~quix0r@dslb-094-221-151-171.pools.arcor-ip.net] has joined #openttd
02:23:35  <donoteat> I hope silence doesn't mean "no"
02:26:35  *** rhaeder1 [~quix0r@dslb-094-221-134-120.pools.arcor-ip.net] has joined #openttd
02:30:48  *** rhaeder [~quix0r@dslb-094-221-151-171.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
02:31:40  * donoteat starts over the scenario :|
02:35:09  *** sylf [~sylf@ip68-102-171-119.ks.ok.cox.net] has quit [Read error: Connection reset by peer]
02:36:25  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd
02:38:56  *** DDR_ [~chatzilla@66.183.117.37] has joined #openttd
02:40:58  *** sylf [~sylf@ip68-102-171-119.ks.ok.cox.net] has joined #openttd
02:45:29  *** DDR [~chatzilla@66.183.117.37] has quit [Ping timeout: 480 seconds]
02:46:39  *** sylf [~sylf@ip68-102-171-119.ks.ok.cox.net] has quit [Read error: Connection reset by peer]
02:47:12  *** rtypo [rtypo@pc54.clicknet.iasi.rdsnet.ro] has quit []
02:57:27  *** DDR [~chatzilla@66.183.117.37] has joined #openttd
03:01:29  *** DDR_ [~chatzilla@66.183.117.37] has quit [Ping timeout: 480 seconds]
03:08:28  *** donoteat [~chatzilla@ip68-100-180-162.dc.dc.cox.net] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]]
03:22:20  *** Tennel [~Tennel@port-ip-213-211-212-60.reverse.mdcc-fun.de] has joined #openttd
03:39:28  *** Tennel [~Tennel@port-ip-213-211-212-60.reverse.mdcc-fun.de] has quit [Quit: Verlassend]
03:43:33  *** DDR_ [~chatzilla@66.183.117.37] has joined #openttd
03:48:29  *** DDR [~chatzilla@66.183.117.37] has quit [Ping timeout: 480 seconds]
03:48:29  *** DDR_ is now known as DDR
03:51:55  *** Zahl [~Zahl@2a01:198:5c1:0:20c1:d3c8:ae47:f8b0] has joined #openttd
04:00:50  *** DDR_ [~chatzilla@66.183.117.37] has joined #openttd
04:06:29  *** DDR [~chatzilla@66.183.117.37] has quit [Ping timeout: 480 seconds]
04:06:31  *** nicfer [~nicfer@190.50.12.214] has joined #openttd
04:06:32  *** DDR_ is now known as DDR
04:30:39  *** DDR [~chatzilla@66.183.117.37] has quit [Quit: In democracy it's your vote that counts; In feudalism it's your count that votes.   - Mogens Jallberg]
04:39:05  *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd
04:50:45  *** keoz [~keikoz@pha75-8-82-230-2-115.fbx.proxad.net] has joined #openttd
04:56:02  *** Eddi|zuHause2 [~johekr@p54B779BA.dip.t-dialin.net] has quit [Remote host closed the connection]
04:56:22  *** Eddi|zuHause2 [~johekr@p54B75CE0.dip.t-dialin.net] has joined #openttd
05:01:51  *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Read error: Operation timed out]
05:41:53  *** TruePikachu [~chris@cpe-67-49-42-88.socal.res.rr.com] has quit [Quit: leaving]
05:44:48  <andythenorth> does this check find me desert?  http://pastebin.com/Hm3xcdtA
05:45:01  <andythenorth> http://wiki.ttdpatch.net/tiki-index.php?page=VarAction2IndustryTiles
05:45:21  <andythenorth> var 60, shift 10, mask 1, check for 1 (1=desert)
05:45:38  <andythenorth> hmm
05:45:49  <andythenorth> shift 0A might be more appropriate :P
05:52:46  *** ar3k [~ident@87-239-75-101.internetia.net.pl] has quit [Read error: Connection reset by peer]
05:53:11  *** ar3k [~ident@87-239-75-101.internetia.net.pl] has joined #openttd
06:11:04  *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has quit [Ping timeout: 480 seconds]
06:11:05  *** devilsadvocate [~devilsadv@202.3.77.41] has quit [Ping timeout: 480 seconds]
06:19:36  *** Wolf01 [~wolf01@host176-238-dynamic.0-87-r.retail.telecomitalia.it] has joined #openttd
06:19:48  <Wolf01> hello
06:23:22  *** Kurimus [Kurimus@dsl-tkubrasgw1-fe34dc00-202.dhcp.inet.fi] has joined #openttd
06:31:58  *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has joined #openttd
06:38:04  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds]
06:38:10  *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has joined #openttd
06:40:09  *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has quit [Ping timeout: 480 seconds]
07:00:02  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd
07:09:48  *** lennard [lennard@lennardk2.student.utwente.nl] has quit [Ping timeout: 480 seconds]
07:14:40  *** Br33z4hSlut5 [~Br33z4hSl@92.68.154.34] has joined #openttd
07:29:21  <Terkhen> good morning
07:36:05  <planetmaker> moin moin
07:41:27  *** JVassie_ [~James@92.27.149.231] has joined #openttd
07:45:38  <Rubidium> planetmaker: your code of FS#4056 doesn't work for me "sed: can't read s/^OPENTTD.GRF  = [0-9a-f]*$/OPENTTD.GRF  = d4c3f8d93c85136203feb7159151beb5/: No such file"
07:48:42  <Rubidium> planetmaker: does it still work for you if you remove the space between the -i and ""?
07:49:50  <planetmaker> let's see
07:52:19  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds]
07:53:40  <planetmaker> nope, it fails: sed: 1: "/Users/ingo/ottd/fixing ...": command i expects \ followed by text
07:54:17  <Rubidium> s/-i/--in-place=/?
07:55:59  <planetmaker> that option doesn't exist
07:56:29  <Rubidium> yay... temporary file, here we come!
07:59:12  <Rubidium> planetmaker: http://rbijker.net/openttd/fs4056.diff
08:00:14  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #openttd
08:00:40  *** ecke [~ecke@188.75.128.2] has quit [Quit: more listen, more understand, more know]
08:01:07  <jordi> Rubidium: wow, the debian email is probably more detailed than any I have written before
08:01:18  <jordi> Rubidium: I don't think any of the requests will face big opposition
08:01:29  <jordi> openmsx is just data, nothing that can "break"
08:01:55  <Rubidium> jordi: I hope the requests will be granted, but I'm more interested in the "date" question :)
08:02:36  <planetmaker> positive, Rubidium :-)
08:03:53  <dihedral> morning
08:03:58  <jordi> Rubidium: I don't think that's any concern
08:04:21  <jordi> I just came back from a loooong trip, but I don't think Debian is releasing anytime "soon"
08:04:54  <Rubidium> jordi: they hope to do it this year
08:05:23  <dihedral> well - that is soon in terms of debians release cycle ^^
08:06:08  *** Progman [~progman@p57A1D39F.dip.t-dialin.net] has joined #openttd
08:07:42  <CIA-2> OpenTTD: rubidium * r20551 /trunk/Makefile.grf.in: -Fix [FS#4056]: apparantly Mac OS X's sed and GNU's can't decide on a single "format" for replacing stuff in-place
08:08:12  <Rubidium> dihedral: the freeze came almost a month earlier than most expected, although you could see signs of it the day before the freeze happened
08:09:51  <jordi> Rubidium: ie, not "soon" :)
08:10:04  *** nicfer [~nicfer@190.50.12.214] has quit [Read error: Connection reset by peer]
08:10:21  <planetmaker> Rubidium, : "The -E, -a and -i options are non-standard FreeBSD extensions and may not be available on other operating systems"
08:10:30  <planetmaker> so fjb would have problems, too ;-)
08:10:40  <Rubidium> nah, he doesn't have nforenum :)
08:10:45  <planetmaker> :-P
08:12:05  <dihedral> am i to interprete r20551 as a OSX Fix?
08:12:11  <jordi> Rubidium: fwiw, I expected the freeze on March :)
08:12:18  <planetmaker> dihedral, yes
08:12:31  <planetmaker> but not only
08:12:36  <planetmaker> 66% yes ;-)
08:12:41  <Rubidium> jordi: that's more when mr. Shuttleworth wanted it to happen :)
08:13:16  <jordi> heh sure :)
08:13:24  <Rubidium> jordi: in any case, my reasoning was to be clear and give an answer to most of the conceivable questions the release team has so it doesn't need mailing back and forth for a few times
08:13:29  <jordi> but in Debconf9, it seemed a good date for some
08:13:43  <jordi> yeah, the email was good
08:13:53  <peter1138> the announced early freeze was recinded the next day
08:13:57  <peter1138> but that wasn't announced
08:14:19  <peter1138> let's go for retracted, as i can't spell
08:14:20  <Rubidium> I liked the freeze during the release team's speech on debconf10
08:15:18  <jordi> is there any ongoing effort to pursue authors of the bits and pieces that make up opensfx in order to GPL it?
08:16:05  <Rubidium> jordi: nope
08:20:19  <Rubidium> let me say that I haven't had real incentives to work on it since December
08:20:36  <Rubidium> and nobody else seems to care enough about it either
08:22:09  *** TB is now known as TrueBrain
08:22:22  <CIA-2> OpenTTD: terkhen * r20552 /trunk/src/ (misc_gui.cpp window.cpp): -Fix: Never show tooltips when the mouse cursor is outside the window.
08:24:32  *** TomyLobo [~foo@port-212-202-171-176.dynamic.qsc.de] has joined #openttd
08:24:46  * Rubidium wonders if there's anyone in here that manages to "create" more than 4 commands per "frame_freq" (for the sane values of frame_freq, i.e. <= 10) frames by manual gameplay
08:25:26  <planetmaker> how long is a frame?
08:25:34  <Rubidium> normally 1 tick
08:25:40  <planetmaker> hm. so 1/74
08:26:01  <Rubidium> so 30 ms, 10 frames = 300 ms
08:26:09  <planetmaker> well. A large piece of TF is one command, right?
08:26:17  <Rubidium> yes
08:26:17  <planetmaker> And a long rail track as well
08:26:23  <Rubidium> yes
08:26:32  <planetmaker> refit for a wagon chain also?
08:26:43  <Rubidium> should be
08:27:08  <Rubidium> yes, it is
08:27:28  <planetmaker> overbuilding stations and track conversions?
08:27:39  <Rubidium> restoring a vehicle's orders (from backup) when buying a vehicle = 1 commands as well
08:27:44  <Rubidium> planetmaker: those are as well
08:28:00  <Rubidium> the only thing I can think of is cloning vehicles like a mad man
08:28:00  <planetmaker> :-) the vehicle commands was clear from the last commits ;-)
08:28:10  <planetmaker> One cannot clone pretty fast
08:28:34  <planetmaker> same with buying
08:28:49  <Rubidium> although... 4 clicks in 300ms is still a lot
08:28:52  <planetmaker> what about a group of shared vehicles which get new orders?
08:29:04  <planetmaker> 4 clicks in 300ms is feasable
08:29:37  <planetmaker> new orders as in: goto + click on another vehicle not in group
08:29:39  <Rubidium> 104 times in 10 seconds seems to be the world record (or was one)
08:29:57  <Rubidium> planetmaker: that's one command as well
08:30:30  <planetmaker>  !rcon ban 78.144.*.* ?
08:31:08  <planetmaker>  !rcon list_settings *pf*
08:31:17  <planetmaker> (or similar, I don't know exact syntax)
08:31:38  <Rubidium> list_settings isn't a command (or trigger any)
08:31:47  <planetmaker> hm, true
08:31:57  <Rubidium> changing a setting triggers one
08:32:10  <planetmaker> but no mass-change possible ;-)
08:32:18  <Rubidium> banning might trigger one for each banned person if they had an orderbackup open
08:32:35  <peter1138> building a depot
08:33:20  <Rubidium> peter1138: hmm, that's 3-ish at most? As the road building happens in a callback
08:33:32  <peter1138> aye
08:34:27  <planetmaker> build bridge?
08:34:34  <Rubidium> so processing 4 commands per client every "frame_freq" frames wouldn't hamper anyone's gameplay if frame_freq is reasonable low
08:35:06  <Rubidium> and queueing up to 32 commands before killing the connection
08:36:10  <planetmaker> outgoing ones?
08:36:24  *** Eddi|zuHause2 is now known as Eddi|zuHause
08:36:25  <Rubidium> building bridges doesn't connect roads
08:36:35  <Rubidium> planetmaker: no, incoming ones
08:36:42  <planetmaker> Incoming?
08:36:50  <Rubidium> yes, commands coming from clients
08:36:51  <planetmaker> But... every player may do as many things
08:37:02  <planetmaker> And have 25 clients, everyone busy...
08:38:01  <Rubidium> planetmaker: but 32 commands per client in a queue, that means that for it needs to send 8 commands each frame for 8 frames (frame_freq = 1)
08:38:17  <Rubidium> it = any of your clients
08:39:11  <planetmaker> ah
08:39:55  <Rubidium> in any case, the numbers are all configurable 1..65535
08:43:23  <Rubidium> I think that setting it to 1 command per frame and 8 commands in queue won't be even noticable
08:43:41  <Rubidium> although that requires real-life testing :)
08:44:09  <peter1138> -> trunk
08:44:09  <peter1138> :D
08:44:26  <Rubidium> it'll break the dump all at once pasting of "templates" though
08:44:28  <peter1138> does this have a purpose, or is it just anti-copy-paste? :p
08:44:43  *** Chris_Booth [~chatzilla@client-86-29-114-124.glfd.adsl.virginmedia.com] has joined #openttd
08:44:46  <planetmaker> I guess anti-bot ;-)
08:45:08  <Rubidium> peter1138: it's anti-person-who-is-trying-to-dos the server
08:45:25  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
08:45:26  <Rubidium> by e.g. sending loads and loads of expensive-to-test, but still failing, commands
08:45:56  <peter1138> I see.
08:46:44  <Rubidium> the anti-bot/anti-copy-paste is more a beneficial side effect, although this won't totally break them or disallow them
08:47:07  <Rubidium> as long as they limit the amount of commands they send each frame_freq frames
08:52:15  *** FlyveHest|Work [~svend@hq.comendo.com] has joined #openttd
08:52:42  <FlyveHest|Work> hi all, a completely newb question here
08:53:03  <FlyveHest|Work> i am setting up a dedicated server, and want to add some of the ECS vectors
08:53:18  <FlyveHest|Work> what do i do about busses/train wagons to transport that cargo?
08:53:34  <planetmaker> add a newgrf which supports them
08:53:38  <FlyveHest|Work> what grf do I need to add for those?
08:53:51  <planetmaker> nearly any vehicle newgrf found on bananas supports it
08:54:04  <FlyveHest|Work> planetmaker: which one would you recommend? i cant seem to find info om the ecs wiki about this
08:54:13  <planetmaker> I don't recommend any :-)
08:54:28  <planetmaker> They're all good. It's a matter of personal taste
08:54:40  <planetmaker> and of what fits the scenario
08:54:53  <planetmaker> but before you setup a dedicated server, test them locally
08:54:54  <planetmaker> :-)
08:55:20  <FlyveHest|Work> thats what i'm doing currently
08:55:23  <FlyveHest|Work> :)
08:56:03  <FlyveHest|Work> something like eGRVTS would work?
08:56:07  <planetmaker> sure
08:56:19  <FlyveHest|Work> perfect, i'll try that .. thanks :)
08:56:34  <planetmaker> also add trains which support that ;-)
08:56:46  <planetmaker> egrvts is only road + tram
08:58:02  <FlyveHest|Work> ah, ok, thats why there aren't any train wagons :)
08:58:14  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd
08:58:26  <FlyveHest|Work> is there a train equivalent to egrvts?
08:58:30  <planetmaker> egrvts = extended generic road vehicle set ;-)
08:58:44  <planetmaker> oh. t = tram
08:59:00  <planetmaker> as said: any train set found probably does the trick
08:59:16  <planetmaker> ukrs, nars2, 2cctrainset, ...
08:59:48  <CIA-2> OpenTTD: rubidium * r20553 /trunk/src/ (9 files in 5 dirs): -Feature: allow rate limiting of incoming commands
09:02:43  *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has joined #openttd
09:04:27  <FlyveHest|Work> how do you refit a cargo wagon?
09:04:35  <FlyveHest|Work> sorry for the, probably, stupid questions :)
09:05:13  <planetmaker> http://wiki.openttd.org/Refit
09:05:14  <Terkhen> http://wiki.openttd.org/Refit
09:05:21  <planetmaker> :-)
09:05:21  <Terkhen> :P
09:05:39  <planetmaker> obviously it was a stupid question :-P
09:06:25  <FlyveHest|Work> found it :)
09:06:30  <FlyveHest|Work> i'll google first, ask later ;)
09:06:33  <FlyveHest|Work> thanks
09:06:38  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds]
09:08:25  <Eddi|zuHause> <FlyveHest|Work> is there a train equivalent to egrvts? <-- try "old wagons, new cargoes"
09:10:26  <FlyveHest|Work> Eddi|zuHause: will that "just" make the old wagons refittable?
09:10:30  *** [hta]specx [~opera@ip94-126-210-87.adsl2.static.versatel.nl] has joined #openttd
09:10:35  <Eddi|zuHause> FlyveHest|Work: yes.
09:10:45  <FlyveHest|Work> could be that I should try that, then
09:11:20  <FlyveHest|Work> but, I think that maybe i'll just run stock settings until me and the other players are comfortable with ottd .. all the different industrytypes, busses and wagons, its a bit overwhelming :)
09:12:12  <planetmaker> playing vanilla is not the worst thing to do
09:12:38  <planetmaker> Using newgrfs sparingly is also nearly always a good idea :-)
09:13:36  <planetmaker> FlyveHest|Work, if you want to get ideas for arrangements, you might looks through a few savegames from our PublicServer savegame list; even though, also not every savegame is really running a completely sane choice there, too
09:13:51  <planetmaker> http://wiki.openttdcoop.org/PublicServer:Archive
09:14:22  <planetmaker> also, of course, the list of newgrfs ages. As such the newer savegames might be more interesting in that respect than older ones
09:15:04  <FlyveHest|Work> planetmaker: arrangements of newgrfs?
09:15:21  <planetmaker> selection. Choice.
09:15:28  <FlyveHest|Work> ok
09:15:51  <planetmaker> sometimes order of newgrf matters.
09:16:05  <planetmaker> But don't worry about that (now)
09:16:05  <FlyveHest|Work> i read that somewhere, yes
09:16:31  <FlyveHest|Work> i wont .. the most interesting thing for me would be to add some new industries, to expand the route possibilities
09:16:39  <OwenS> w00t
09:16:40  <OwenS> awesome
09:16:42  <OwenS> "Congratulations! Your place at The University of Sheffield (S18) to study Physics (4 years) (F301) has been confirmed. "
09:17:12  <planetmaker> congratz
09:17:26  <planetmaker> welcome to the path to improved nerdyness and geek-dom
09:17:34  <FlyveHest|Work> but, playing vanilla until we "get it" is probably a pretty good idea :)
09:17:44  <FlyveHest|Work> its been some years since I last played TTD ;)
09:17:55  <planetmaker> FlyveHest|Work, then it's a pretty good idea :-)
09:18:06  <FlyveHest|Work> we had a blast 5 people last night, though, sitting on mumble and generally totally messing up the world ;)
09:18:08  <FlyveHest|Work> great fun
09:18:09  <OwenS> OK. Knowns: I got two As and a B, at least :P Now, to finish breakfast, get dressed & showered, and go into college to find out what exactly :p
09:19:48  <planetmaker> in 2 to 3 years you'll find also joy in integrating the banana space ;-)
09:20:17  <planetmaker> though hilbert space is usually sufficient ;-)
09:20:26  <OwenS> ;-P
09:21:56  <planetmaker> and you'll know what's funny about calling it banana space :-P
09:22:18  <Rubidium> yeah, that it's filled by NewGRF devs
09:23:40  <planetmaker> hehe
09:24:29  <planetmaker> are they integrable on the L^2 norm?
09:24:56  <planetmaker> at least the function space is infinite ;-)
09:31:04  *** Kurimus [Kurimus@dsl-tkubrasgw1-fe34dc00-202.dhcp.inet.fi] has quit [Ping timeout: 480 seconds]
09:31:13  *** Kurimus [Kurimus@dsl-tkubrasgw1-fe34dc00-202.dhcp.inet.fi] has joined #openttd
09:32:22  *** Lachie_ [whitey@creep.bur.st] has joined #openttd
09:32:22  *** Lachie [whitey@creep.bur.st] has quit [Read error: Connection reset by peer]
09:33:42  *** thvdburgt [~thvdburgt@banning.xs4all.nl] has joined #openttd
09:34:19  *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd
09:43:49  *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has joined #openttd
09:50:16  *** Tennel [~Tennel@port-ip-213-211-212-60.reverse.mdcc-fun.de] has joined #openttd
10:02:08  *** perk11 [~perk11@85.175.111.168] has joined #openttd
10:08:02  <Hirundo> To what extent is different enums having the same XY_prefixes a problem?
10:08:53  <Rubidium> it'll definitely be confusing
10:10:14  <OwenS> Overall results: AABb [with an a from last year] :)
10:10:52  <Hirundo> Even if the code sections in which they are used don't overlap?
10:11:41  *** FlyveHest|Work [~svend@hq.comendo.com] has quit [Quit: Bente-Bent og Katja-Kaj]
10:12:16  *** andythenorth [~andytheno@salieri.openttdcoop.org] has quit [Read error: Connection reset by peer]
10:12:16  *** Terkhen [~Terkhen@salieri.openttdcoop.org] has quit [Read error: Connection reset by peer]
10:12:16  *** V453000 [~V453000@salieri.openttdcoop.org] has quit [Remote host closed the connection]
10:12:16  *** Ammler [~ammler@salieri.openttdcoop.org] has quit [Write error: connection closed]
10:12:16  *** Hirundo [~Hirundo@salieri.openttdcoop.org] has quit [Write error: connection closed]
10:15:23  *** Timmaexx [~quassel@port-92-201-136-73.dynamic.qsc.de] has joined #openttd
10:21:32  *** Hirundo [~Hirundo@salieri.openttdcoop.org] has joined #openttd
10:21:37  *** Ammler [~ammler@salieri.openttdcoop.org] has joined #openttd
10:23:02  *** Terkhen [~Terkhen@salieri.openttdcoop.org] has joined #openttd
10:23:33  *** V453000 [~V453000@salieri.openttdcoop.org] has joined #openttd
10:24:32  *** andythenorth [~andytheno@salieri.openttdcoop.org] has joined #openttd
10:25:41  *** Aali [~aali@h-90-31.A189.priv.bahnhof.se] has quit [Quit: leaving]
10:36:09  <Eddi|zuHause> what's an AABb?
10:37:18  *** lugo [~lugo@mgdb-4db8c12f.pool.mediaWays.net] has joined #openttd
10:48:36  *** Timmaexx_ [~quassel@port-92-201-136-73.dynamic.qsc.de] has joined #openttd
10:55:12  <dihedral> Hirundo, what do you want to duplicate??
10:55:45  <planetmaker> Eddi|zuHause, grades
10:55:45  <Hirundo> SC_xx, currently used for screenshots
10:56:13  <planetmaker> anglo-saxon grades are A-a-B-b-C-D-fail
10:56:25  <planetmaker> maybe D is already fail, dunno
11:10:14  <TomyLobo> no
11:10:21  <TomyLobo> anglo-saxon grades are just fail
11:11:13  *** FlyveHest|Work [~svend@hq.comendo.com] has joined #openttd
11:13:52  <FlyveHest|Work> can you abandon a company while playing on a dedicated server?
11:14:34  <TomyLobo> yes, why not?
11:14:48  <TomyLobo> if you want to get rid of it, make sure it has no money left :)
11:14:58  <FlyveHest|Work> how do you do that? Is it by using the console?
11:15:04  <TomyLobo> eh?
11:15:15  <FlyveHest|Work> not as the server administrator, but as a regular player :)
11:15:15  <Ammler> sell all vehicles
11:15:25  <FlyveHest|Work> and autocleaning is disabled :)
11:15:35  <Eddi|zuHause> then you can't
11:15:38  <Ammler> why do you care?
11:15:49  <TomyLobo> cause there is a max of companies :)
11:15:57  <FlyveHest|Work> i can see that there is a reset_company command in the console
11:16:00  <FlyveHest|Work> TomyLobo: exactly
11:16:06  <TomyLobo> and he wants to make a company and restructure the landscape with it :)
11:16:15  *** Aali [~aali@h-90-31.A189.priv.bahnhof.se] has joined #openttd
11:16:22  <CIA-2> OpenTTD: rubidium * r20554 /trunk/config.lib: -Fix [FS#4057]: typo in configure --help
11:16:28  <FlyveHest|Work> and, my current company has gone down the drain, i just want to restart, without bothering the rest of the players
11:17:06  <Ammler> join a server with support or more companies
11:17:08  <FlyveHest|Work> i couldn't see an option in the GUI, and I am not sure about the reset_company function in the console
11:17:24  <FlyveHest|Work> Ammler: thanks, but that doesn't really answer my question :)
11:17:35  <Ammler> your question is answered already
11:18:17  <FlyveHest|Work> selling all vehicles will remove the company immediately
11:18:18  <FlyveHest|Work> ?
11:18:30  <Ammler> [13:15] <Eddi|zuHause> then you can't
11:18:38  <FlyveHest|Work> ok
11:18:57  <FlyveHest|Work> seems like a strange omision, i might add
11:19:09  <FlyveHest|Work> but i'll just use admin powers to remove it, then
11:19:36  <Ammler> :-o
11:19:53  <Ammler> you are admin but not able to setup autoclean?
11:20:06  <FlyveHest|Work> its not that i'm not able to, i just don't want it on
11:20:13  <FlyveHest|Work> its not a public server
11:20:30  *** JakeGrimshaw [~jake.grim@5ad30319.bb.sky.com] has joined #openttd
11:20:37  <Ammler> what is the issue with the novehicle_autoclean?
11:22:26  *** devilsadvocate [~devilsadv@202.3.77.41] has joined #openttd
11:22:31  <FlyveHest|Work> seems like I have to enable company autoclean alongside novehicles
11:22:33  <JakeGrimshaw> I don't suppose anyone knows the code to embed a youtube video in a post on the forums ?
11:22:44  <FlyveHest|Work> or can I disable the company autoclean by setting them to 0?
11:23:16  <FlyveHest|Work> the wiki mentions this on autoclean_unprotected, but not in protected
11:24:39  <FlyveHest|Work> i'll try
11:28:36  <Ammler> yes, try :-)
11:29:04  <Ammler> maybe update the wiki, if it isn't "clear"
11:29:54  *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd
11:29:57  *** extspotter [~extspotte@host86-133-55-30.range86-133.btcentralplus.com] has joined #openttd
11:30:20  <FlyveHest|Work> it cleaned two companies, so somethings working :)
11:31:40  *** extspotter [~extspotte@host86-133-55-30.range86-133.btcentralplus.com] has quit [Quit: Bye for now!]
11:33:27  <CIA-2> OpenTTD: yexo * r20555 /trunk/src/ (ai/ai_gui.cpp graph_gui.cpp lang/english.txt): -Fix [FS#4053]: wrong tooltip for the company select button in the AI debug and performance rating windows
11:35:33  *** JakeGrimshaw [~jake.grim@5ad30319.bb.sky.com] has quit []
11:36:25  <CIA-2> OpenTTD: yexo * r20556 /trunk/src/ai/ai_gui.cpp: -Fix (r20555): a tempory copy/pasted line ended up in the commit
11:37:38  <VVG> hello
11:37:43  <avdg> hey
11:38:48  <VVG> I want the timetable to start at day X and _date_fract Y. So i supply the start date with dayX and set vehicle lateness_counter to _date_fract Y. Will that work?
11:38:59  *** fmauneko [~fmauneko@134.227.101-84.rev.gaoland.net] has joined #openttd
11:39:21  <fmauneko> hai
11:39:27  <avdg> hai
11:39:33  <VVG> hey
11:41:49  <Eddi|zuHause> VVG: that sounds wrong
11:41:51  *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has quit [Ping timeout: 480 seconds]
11:43:33  <VVG> :(
11:43:35  <VVG> In what way?
11:44:04  <Rubidium> timetable start resetting he lateness?
11:44:13  *** FlyveHest|Work [~svend@hq.comendo.com] has quit [Quit: Bente-Bent og Katja-Kaj]
11:45:27  <VVG> that, i thought about first calling timetablestart cmd, then call set vehicleontime cmd modded to use p2 parameter for lateness_counter
11:46:28  <VVG> or does lateness also resets when timetable actually starts?
11:46:50  <Hirundo> Why is such precise control of timetable start time important to you?
11:47:06  <VVG> for virtual time system patch
11:48:22  <Rubidium> VVG: the latenesscounter won't work
11:48:37  <Rubidium> it will be reset for each and every order that is not order 0
11:48:48  <Rubidium> and the timetable_start date only comes into play at order 0
11:49:22  <Rubidium> and then the timetable_state date sets the lateness counter to "current time" - "start time"
11:50:00  <Hirundo> VVG: like in PhilSophus' old timetable patch?
11:50:38  <VVG> yeah, i'm trying to update vt system from that patch to current trunk
11:52:50  <Rubidium> there's somewhat a design disagreement between ITiM and what I put in trunk (or would like in trunk)
11:52:51  <VVG> Rubidium: does resetting it later actually matters? The timetable lentgh will be in x amount of ticks anyway.
11:53:06  *** Timmaexx_ [~quassel@port-92-201-136-73.dynamic.qsc.de] has quit [Remote host closed the connection]
11:54:03  <Rubidium> e.g. ITiM reduced the "range" of date significantly so he could put _date_fract in the same 32 bits, however that'll again break horribly with longer days (more ticks a day)
11:54:53  <VVG> i don't get that
11:56:03  <Rubidium> and limiting the date to 2400 if you want to allow a day to take 32 times as long as it does now doesn't make much sense
11:57:08  <VVG> how that comes into play with purely virtual time?
11:57:10  <Rubidium> VVG: ITiM and the daylength patch do not work together
11:58:03  <VVG> i'm not trying to do anything with daylenght
11:58:45  <Rubidium> VVG: because the 32bits virtual time "clock" limits the range of dates by a factor DAY_TICKS. The daylength patch increases DAY_TICKS, thus reducing the range of dates even more
12:00:00  <Rubidium> regardless of whether you were thinking about that, I was thinking about it when I "changed" trunk's CmdSetTimetableStart to the current behaviour
12:00:33  <Rubidium> the solution is relatively simple: just add a second timetable_start variable for the amount of ticks from the start date
12:01:19  <dihedral> VVG, you are getting some very good hints
12:01:25  <dihedral> i can only suggest to follow them ;-)
12:02:34  <CIA-2> OpenTTD: rubidium * r20557 /trunk/known-bugs.txt: -Document [FS#3928]: why we won't fix the issue
12:02:35  <VVG> i'm trying to understand them right now
12:04:48  *** Timmaexx_ [~quassel@port-92-201-136-73.dynamic.qsc.de] has joined #openttd
12:05:41  *** Timmaexx [~quassel@port-92-201-136-73.dynamic.qsc.de] has quit [Remote host closed the connection]
12:05:41  *** Timmaexx_ [~quassel@port-92-201-136-73.dynamic.qsc.de] has quit [Remote host closed the connection]
12:07:45  <VVG> 1st, i dont understand hiw daylength patch came into mentioning, it surely is out of the scope of my current interests.
12:09:25  <VVG> 2nd, why does limiting date to 2400 matters for virtual time? I'm lost here too :(
12:09:41  *** Fuco [~dota.keys@188.123.106.105] has joined #openttd
12:09:44  *** Tennel [~Tennel@port-ip-213-211-212-60.reverse.mdcc-fun.de] has quit [Quit: Verlassend]
12:11:09  <VVG> I'm surely lacking some fundamental knowledge to understand what's going on :(
12:28:48  *** KenjiE20 [~KenjiE20@92.19.165.204] has joined #openttd
12:29:37  <Hirundo> Basically, you should not store Date * DATE_TICKS in a single 32-bit number, because of overflow problems
12:30:51  <Hirundo> to prevent overflows, ITiM reduce MAX_DATE by factor 74 (DAY_TICKS), limiting dates to around 2400 AD, which is bad (tm) as well
12:37:14  <VVG> Does that mean, that if i switch int32 vars in vt patch to int64 it will be ok and there won't be a need to limit current max year by a factor of 74?
12:42:46  <avdg> I guess you can do the math on your own :p
12:45:25  <Belugas> hello all
12:45:40  <Goulp> Hello alone
12:50:20  *** glx [glx@2a01:e35:2f59:c7c0:ed96:839a:fabd:bf03] has joined #openttd
12:50:23  *** mode/#openttd [+v glx] by ChanServ
12:51:15  <TomyLobo> where do dates start?
12:51:17  <TomyLobo> 0?
12:51:32  <TomyLobo> you could just make them start at 1500 and end up with a max date of 3900
12:51:57  <glx> max is around 32000000
12:52:30  <TomyLobo> 32000000 what?
12:53:17  <Belugas> years, of course
12:53:29  <Rubidium> glx: more 5 million years
12:53:47  <glx> yes my brain failed
12:55:16  <Rubidium> TomyLobo: then you'd still be limiting the current range and breaking (some) savegames unnecessarily
12:55:19  <VVG> hm
12:55:46  <VVG> what could be possible the reason to use int32 to store virtual time and limit max dates, instead of using int64?
12:56:08  <TomyLobo> limited memory :D
12:56:11  <Rubidium> passing int64 in a command is kinda tricky
12:56:50  <avdg> humm does it really need that much more space? :p
12:56:53  <CIA-2> OpenTTD: yexo * r20558 /trunk/src/ (ai/ai_gui.cpp graph_gui.cpp widget.cpp widget_type.h): -Codechange: use one generic function to create a list of company buttons
12:57:40  <Belugas> Yexo, make it a plugin function!
12:57:42  * Belugas hides
12:57:59  <Yexo> hehe
12:58:08  *** Chris_Booth is now known as Guest113
12:58:19  <peter1138> surely it shuld be company knobs
12:58:26  <peter1138> leading the way to the undo knob
12:58:46  <Belugas> lol
13:04:00  <TomyLobo> avdg twice as much!
13:04:02  <TomyLobo> ^^
13:05:28  <VVG> from what i understand, it needs int64 only when calculating seconds passed since day 1 year 0. And that is used in just a handful of places.
13:06:56  <avdg> tomyLobo: yep, twice as much, but it still doesn't mean that openttd uses double the memory then
13:09:03  <planetmaker> VVG, that's in a lot of places
13:09:05  <Belugas> VVG, where? in RL  computing or in OpenTTD's computing?
13:10:01  <VVG> openttd
13:10:37  <Rubidium> planetmaker: why? It's just in visualisation and for determining the parameters to the timetable start command
13:11:09  <Rubidium> internally OpenTTD should be quite happy to run with the current stuff
13:12:20  <Rubidium> the "ony" thing is the timetable start 'tick' offset
13:12:55  <Rubidium> when that is done it is conceivable that the whole virtual time is/can be done at client side
13:16:08  <planetmaker> Rubidium, you mean just a scaling factor for the display?
13:16:16  <Rubidium> yes
13:16:27  <planetmaker> hm, probably makes sense most
13:16:39  <Rubidium> that's what the whole virtual time stuff is
13:16:41  <planetmaker> and least messing with stuff. Especially compatibility...
13:17:36  <Rubidium> with a few hooks via commands, though those operate mostly on ticks (which is the smallest a time unit can be as well), except the start date
13:17:49  <Rubidium> which has some space to pass an offset in ticks from that particular start date
13:18:03  <Rubidium> start date command that is
13:22:30  <VVG> to me, it seemed easier to pass tick offset, if it's needed, through cmdsetvehicleontime as lateness_counter, since it's already there. If the whole timetable lenght is being counted in ticks, then that means offest matters only at first start of timetable.
13:28:10  <Hirundo> VVG: It may be easier to have 1 day == n virtual minutes, instead of 1 tick == n virtual seconds
13:28:16  <Rubidium> VVG: commands take time to get over the network, so if you say: start in 20 ticks and the network takes 5 ticks to get the command to all clients you actually set it to 25 ticks from the moment you gave the command
13:32:53  <VVG> that's nasty thing to happen
13:35:34  *** trebuchet [~Trebuchet@69.51.104.87] has quit [Quit: Leaving]
13:44:54  <CIA-2> OpenTTD: yexo * r20559 /trunk/src/ (5 files): -Fix [FS#4045]: make sure that all vehicles are build in the most northern depot/hangar tile
13:45:29  *** Zahl [~Zahl@2a01:198:5c1:0:20c1:d3c8:ae47:f8b0] has quit [Quit: *schiel*]
13:58:44  <VVG> is it ok using int64 % int32?
14:02:25  <Hirundo> What can be gained by setting timetables accurate up to a single tick? currently everything is rounded to days and I see no real reason to change that
14:03:01  *** theholyduck [~holyduck@ip-226-136-106-77.eidsiva.net] has quit [Read error: Connection reset by peer]
14:03:24  *** Fuco [~dota.keys@188.123.106.105] has quit [Read error: Connection reset by peer]
14:03:33  <Rubidium> Hirundo: daylength 32?
14:03:41  *** Fuco [~dota.keys@188.123.106.105] has joined #openttd
14:03:51  <Rubidium> maybe you want it to be every 60 ticks?
14:04:08  <Rubidium> more "importantly", months aren't regular so counting it difficult
14:04:33  *** fmauneko [~fmauneko@134.227.101-84.rev.gaoland.net] has quit [Ping timeout: 480 seconds]
14:05:42  <Hirundo> As I said, why not set one (or more) virtual minute(s) to be equal to one day and do away with the virtual second
14:05:49  <VVG> Internally, timetable works in ticks, right?
14:05:57  *** theholyduck [~holyduck@ip-226-136-106-77.eidsiva.net] has joined #openttd
14:06:02  <Hirundo> Yes, but all values are rounded to days
14:06:26  <VVG> values shown?
14:06:47  <Hirundo> autofilled values, and values entered by users entering them in days
14:07:08  <Hirundo> what is shown depends on a gui setting
14:07:15  <VVG> you can enter values in ticks, right?
14:07:54  <Hirundo> yes, I'm not sure whether these are rounded as well
14:08:16  <VVG> wait
14:08:39  *** sylf [~sylf@ip68-103-138-57.ks.ok.cox.net] has joined #openttd
14:08:40  <VVG> internally, it works with exact tick values, right? Only what's shown in gui is rounded.
14:08:55  <VVG> That's what i currently assume.
14:09:52  *** `Fuco` [~dota.keys@188.123.106.105] has joined #openttd
14:12:01  <VVG> okay, with starting year 4999999 virtual time seems to work for me now
14:12:18  <Hirundo> what's shown in gui is rounded in the gui code, but the 'unrounded' values are often a multiple of DAY_TICKS as well
14:13:15  <Rubidium> if you set the "gui" to ticks it won't be rounded (AFAIK)
14:13:18  <VVG> well, you can still enter them in multiple of something else, right?
14:16:55  *** Fuco [~dota.keys@188.123.106.105] has quit [Ping timeout: 480 seconds]
14:18:18  <VVG> Is it ok, if i supple cmdtimetablestartdate with ticks until the timetable start from current moment, do a proper conversion to days inside there and set lateness_counter appropriatly?
14:18:52  <VVG> Rubidium: that advice of yours to use second timetable_start var is something i have no idea how to do :(
14:19:20  <Rubidium> VVG: no, supplying ticks to moment in a Cmd won't work due to the previously described network lag
14:21:34  *** George is now known as Guest117
14:21:38  *** George [~George@212.113.107.39] has joined #openttd
14:22:24  <VVG> even if timetable start is somewhere in the future?
14:23:53  <VVG> oh
14:23:55  <VVG> got it
14:25:01  *** `Fuco` [~dota.keys@188.123.106.105] has quit [Ping timeout: 480 seconds]
14:25:26  <CIA-2> OpenTTD: rubidium * r20560 /trunk/src/ai/api/ai_object.cpp: -Fix: AIs (still/again?) crashing for certain commands
14:26:52  <CIA-2> OpenTTD: rubidium * r20561 /trunk/src/water_map.h: -Fix: compiler warning
14:27:47  *** Guest117 [~George@212.113.107.39] has quit [Ping timeout: 480 seconds]
14:28:01  *** PinguTux [~PinguTux@pD9E9C3B7.dip.t-dialin.net] has joined #openttd
14:28:50  *** PinguTux [~PinguTux@pD9E9C3B7.dip.t-dialin.net] has left #openttd []
14:28:50  *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Read error: Connection reset by peer]
14:29:21  *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd
14:33:27  <VVG> Rubidium: if i were to add second timetable_start var, where should it go?
14:33:27  *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Read error: Connection reset by peer]
14:33:52  <Rubidium> near the first one with some similar, but descriptive name
14:33:57  *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd
14:34:05  <Rubidium> maybe rename timetable_start to timetable_start_date
14:34:13  <Rubidium> and call it timetable_start_ticks_offset
14:35:46  *** perk111 [~perk11@178.34.95.48] has joined #openttd
14:36:09  *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Read error: Connection reset by peer]
14:37:04  *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd
14:37:51  *** perk11 [~perk11@85.175.111.168] has quit [Read error: Connection reset by peer]
14:37:52  *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Read error: Connection reset by peer]
14:38:36  *** Timmaexx [~quassel@port-92-201-136-73.dynamic.qsc.de] has joined #openttd
14:38:40  *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd
14:41:27  *** Fuco [~dota.keys@188.123.106.105] has joined #openttd
14:46:44  *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has quit [Ping timeout: 480 seconds]
14:46:57  *** Biolunar [Mahdi@blfd-4db0fcd0.pool.mediaWays.net] has joined #openttd
14:48:15  *** `Fuco` [~dota.keys@188.123.106.105] has joined #openttd
14:48:26  *** HerzogDeXtEr1 [~Flex@88.130.190.38] has joined #openttd
14:51:35  *** Fuco [~dota.keys@188.123.106.105] has quit [Ping timeout: 480 seconds]
14:52:05  <VVG> not getting it
14:53:09  *** Fuco [~dota.keys@188.123.106.105] has joined #openttd
14:53:58  *** `Fuco` [~dota.keys@188.123.106.105] has quit [Read error: Connection reset by peer]
14:54:28  *** Fuco [~dota.keys@188.123.106.105] has quit []
14:55:26  *** HerzogDeXtEr [~Flex@88.130.162.108] has quit [Ping timeout: 480 seconds]
15:00:25  *** bryjen [~bryjen@63.147.94.149] has joined #openttd
15:02:38  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has quit [Ping timeout: 480 seconds]
15:06:47  *** Chris_Booth [~chatzilla@client-86-29-114-124.glfd.adsl.virginmedia.com] has joined #openttd
15:08:48  *** KouDy [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has joined #openttd
15:17:20  *** Grelouk [~Grelouk@93.21.11.37] has joined #openttd
15:17:23  *** Chris_Booth [~chatzilla@client-86-29-114-124.glfd.adsl.virginmedia.com] has quit [Remote host closed the connection]
15:19:26  *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has joined #openttd
15:19:53  <CIA-2> OpenTTD: yexo * r20562 /trunk/ (14 files in 4 dirs): -Change: [NoAI] Move all functions from AIList to AIAbstractList
15:26:31  <VVG> There is Tileinxded tile param of CmdSetTimetableStart that's not being used there. Is it ok supply the tick offset through it to CmdSetTimetableStart?
15:28:01  <Rubidium> nope, depending on the settings everything from 1..2049 might be seen as invalid tiles and just the command returns an error (i.e. is not executed)
15:37:22  <Rubidium> though there are some free bits in p1
15:37:40  <CIA-2> OpenTTD: yexo * r20563 /trunk/ (50 files in 6 dirs): -Change: [NoAI] rename AIAbstractList to AIList
15:42:03  <planetmaker> now... that looks odd :-)
15:42:46  <planetmaker> mv A/* B; mv B A
15:42:53  <VVG> bits is something i have absolutely no idea about, and can't think of any use for me :(
15:43:39  *** Fuco [~dota.keys@188.123.106.105] has joined #openttd
15:44:29  <CIA-2> OpenTTD: yexo * r20564 /trunk/bin/ai/ (compat_0.7.nut compat_1.0.nut): -Fix (r20562): provide compatibility for AIs using the 0.7/1.0 API and using AIList::ChangeItem
15:50:05  <Rubidium> planetmaker: may look odd, but it retains the most history
15:50:10  *** perk111 [~perk11@178.34.95.48] has quit [Read error: Connection reset by peer]
15:50:51  *** perk11 [~perk11@178.34.32.221] has joined #openttd
15:53:49  <planetmaker> :-)
15:54:10  *** Timmaexx [~quassel@port-92-201-136-73.dynamic.qsc.de] has quit [Remote host closed the connection]
15:58:35  <dihedral> Rubidium, what is it you understand under virtual time (i.e. as mentioned earlier wrt that patch)
15:59:52  <Rubidium> virtual, as it says... not related to the game days in OpenTTD or related to the real outside world time
16:00:27  <dihedral> what purpose would that have, if you introduce time which is not related to real time, nor to the ingame time?
16:00:32  <Rubidium> whatever conversion/visualisation methods I don't really care about
16:00:37  <Rubidium> dihedral: read the backlog
16:01:09  <VVG> it's to get 24h visualisation of timetables
16:01:21  <Rubidium> dihedral: it is some conversion of the in-game date, but not trivial and not necessarily the same
16:02:33  <VVG> dihedral: http://www.tt-forums.net/viewtopic.php?f=47&t=41372&sid=0e999cd78a6a9a2037a3ee39340a93d0 this is what got me interested
16:04:21  *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds]
16:14:23  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd
16:17:04  <VVG> Rubidium: how can i check what bits are free for taking?
16:22:57  *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has joined #openttd
16:32:26  <Ammler> opengfx users, please update to http://bundles.openttdcoop.org/opengfx/nightlies/r493/ and report any issues :-)
16:34:55  <Ammler> on bananas, what is max version for?
16:36:00  <Ammler> only useable for abandoned sets?
16:36:20  <planetmaker> in order to disable things, yes
16:37:24  *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has joined #openttd
16:39:43  <Yexo> Ammler: for example or an AI that used the 1.1 API but is not yet compatible with the latest changes in trunk
16:40:27  *** |Jeroen| [~jeroen@94-224-31-113.access.telenet.be] has joined #openttd
16:40:30  <Ammler> Yexo: but you can't "force" people to update a grf with it?
16:40:58  <Yexo> no, you can always download it with an older openttd version
16:41:12  <Yexo> the maximum version is only used to determine whether or not it's visible in the online content list in openttd
16:41:15  <Ammler> hmm, well, we could implement that in the grf itself
16:42:01  <Yexo> how would you do that?
16:42:17  <planetmaker> disable, if version not to your liking
16:42:23  <Ammler> by disable the grf and a note to run bananas update
16:42:27  <Yexo> yes, but you don't know anything about future versions
16:42:44  <planetmaker> it would be VERY bad newgrf behaviour, yes
16:42:59  <planetmaker> as it breaks basically savegame compatibility
16:43:03  <Ammler> well, if there is no update available :-)
16:43:05  <Yexo> and why would you write a newgrf that disables itself in the currently latest version? imo you'd be far better of updating the newgrf code then implementing that check
16:43:40  <Yexo> Ammler: at the time you create the newgrf it always works in the latest version (assumption), when the newgrf becomes broken due to changes you want to disable it
16:43:58  <Yexo> to disable it you'll have to change the newgrf, so users need to update first only to notice that the update doesn't work
16:43:59  <planetmaker> but only for new downloads
16:44:01  <Ammler> Yexo: not to disable itself, to force people to update
16:44:07  <Yexo> they can still remove the update and play with the older version
16:44:19  <Yexo> you can't force people to update
16:44:42  <planetmaker> luckily :-)
16:44:46  <Yexo> if you upload a newer version to bananas the older versions won't be visible in-game anyway
16:44:52  <Yexo> so there is no need to set a maximum version
16:44:59  <Ammler> but if poeple would like to play with newer openttd, they would need to update
16:45:14  <planetmaker> that's usual
16:45:39  <Yexo> Ammler: yes, but at the time you write the newgrf you don't know from which openttd version on they need an update for the grf
16:46:03  <Yexo> you don't know currenlty whether openttd 1.1 will work with current opengfx, so you can't check in opengfx for opentd version 1.1 and then force the user to upgrade
16:46:09  <planetmaker> but you don't want a newgrf which behaves like the windows genuine talk-back disadvantage verification tool
16:47:15  <planetmaker> "you're running a not-licensed newgrf. Please connect to bananas and make sure you get the newest version, the only one which you can get a license for :-P
16:47:18  <Ammler> yeah, you would do that "on purpose"
16:47:26  <Ammler> hehe
16:48:07  *** [hta]specx [~opera@ip94-126-210-87.adsl2.static.versatel.nl] has left #openttd []
16:49:51  *** ProfFrink [~proffrink@5e0a74b3.bb.sky.com] has joined #openttd
16:52:08  *** Guest113 [~chatzilla@client-86-29-114-124.glfd.adsl.virginmedia.com] has quit [Ping timeout: 480 seconds]
16:52:25  <VVG> CmdSetTimetableStart gets w->windownumber as p1 parameter and uses bits 1-16 from it to get a vehicle id. Am i free to use other bits for myself here?
16:55:53  <Eddi|zuHause> if both the documentation and the code says the other bits are not used, you can use them
16:56:00  *** Prof_Frink [~proffrink@5e0a032e.bb.sky.com] has quit [Ping timeout: 480 seconds]
16:56:00  *** ProfFrink is now known as Prof_Frink
16:59:27  <VVG> except the comments in code, is there some other source of documentation?
17:01:34  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds]
17:03:03  *** TheMask96 [martijn@greed.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
17:04:03  <Ammler> docs
17:08:49  *** TheMask96 [martijn@gluttony.vhost.ne2000.nl] has joined #openttd
17:09:18  *** Grelouk [~Grelouk@93.21.11.37] has quit [Ping timeout: 480 seconds]
17:09:39  *** Sacro [~ben@cpc2-mfld9-0-0-cust880.mfld.cable.virginmedia.com] has joined #openttd
17:15:44  <Yexo> docs.openttd.org, but that's autogenerated from the comments in the code
17:16:01  <Yexo> and there is some documentation on the wiki, but part of that is very outdated/incorrect
17:19:03  <Ammler> (I meant trunk/docs/)
17:21:08  <Rubidium> the wiki is good if you want outdated and 'has never been correct' information
17:21:33  <Rubidium> ^/trunk/docs/ does not have anything that's useful for VVG
17:23:36  *** Zuu [~Zuu@80.251.192.2] has joined #openttd
17:23:47  *** JVassie [~James@92.27.149.231] has joined #openttd
17:24:30  <Zuu> While the wiki per definition never can be completely up to date, I still find it uesful.
17:24:57  <Zuu> It can introduce you into new topics, which you then have to confirm against the source code.
17:26:32  <VVG> Well, in this case, i assumed my judgment of the code was correct and went ahead with using free bits. :)
17:26:45  *** ABD [~ABD@188.48.3.58] has joined #openttd
17:26:56  <ABD> hi
17:27:05  <Zuu> hi
17:27:06  <avdg> vvg: trial and error ^^
17:27:52  *** Intexon [58675045@ircip1.mibbit.com] has joined #openttd
17:28:02  <ABD> i am loohing to play with a groub of people
17:28:02  <ABD> loohing= looking
17:28:02  <ABD> ???
17:28:30  <VVG> avdg: pretty much
17:28:31  <ABD> is it that the reght places
17:28:32  <Zuu> Do you look for people to play with, or do you arleady know those people?
17:28:40  <ABD> no
17:29:00  <ABD> i am looking for people to play with
17:29:14  <Zuu> http://servers.openttd.org <-- list of all advertised servers
17:29:28  <Zuu> OpenTTDCoop usually have people on their servers
17:29:31  <ABD> this is the first time for me to enter the chat room
17:29:35  <Zuu> In addition they do cooperative playing.
17:29:43  *** JVassie_ [~James@92.27.149.231] has quit [Ping timeout: 480 seconds]
17:29:59  <avdg> abd: use version 1.0.3, there are a lot active servers using it atm
17:30:10  <planetmaker> ABD: look at your server list from ingame
17:30:21  <Zuu> openttdcoop -> #openttdcoop on this server
17:30:24  <planetmaker> Join one of those servers where there are a few clients connected
17:30:27  <Zuu> or www.openttdcoop.org
17:30:32  <planetmaker> :-)
17:30:44  <ABD> ok
17:30:59  <planetmaker> But question really is: do you want competitive play or cooperative one :-)
17:31:11  <planetmaker> there are differences as Zuu pointed out ;-)
17:31:23  <ABD> ok
17:31:51  <avdg> abd: can you already build networks?
17:31:54  <planetmaker> I might be biased towards cooperative play ;-)
17:32:32  <planetmaker> which can be found on... yeah, the openttdcoop server(s)
17:32:49  <ABD> good qustion
17:32:52  <ABD> ??
17:33:35  <planetmaker> let me recommend for starters maybe our 'stable' server which runs OpenTTD 1.0.3
17:33:36  <ABD> whrer can i fiund the openttdcoop server??
17:33:45  <ABD> ok
17:33:52  <planetmaker> look for #openttdcoop Stable
17:34:01  <ABD> where
17:34:02  <ABD> ?
17:34:14  <glx> ingame
17:34:18  <ABD> ok
17:34:19  <avdg> tutorials about openttd can be founded on http://wiki.openttd.org/Tutorial
17:34:24  <planetmaker> hm, in the server list? Ingame?
17:34:31  <ABD> ok
17:34:45  <planetmaker> main menu->multiplayer->find servers
17:35:00  <planetmaker> make sure you search in the internet, not in LAN
17:35:23  <ABD> ok
17:35:39  <ABD> can i enter any one
17:35:42  <ABD> or
17:35:49  <avdg> only the green ones
17:35:55  <planetmaker> http://wiki.openttd.org/Multiplayer
17:36:08  <ABD> should i speak with people first
17:36:10  <avdg> you can also join the yellow ones, but you have to install extra stuff
17:36:17  <avdg> just join :)
17:36:28  <ABD> thank you
17:36:36  <ABD> for all of you
17:36:53  <planetmaker> you're welcome
17:37:12  <ABD> have a good play
17:37:16  <avdg> have fun
17:37:27  <ABD> you too
17:37:44  <ABD> Bay
17:37:51  <planetmaker> we do :-) See you
17:37:55  <Zuu> The extra stuff is usually found through the in-game content downloader.
17:38:03  *** ABD [~ABD@188.48.3.58] has quit [Quit: Bye for now!]
17:38:12  <planetmaker> that was quick :-)
17:38:33  <TomyLobo> he might also want to invest in an english course :)
17:39:25  <planetmaker> I've seen worse. Especially by people who are native speakers
17:39:29  <VVG> So. I use Changetimetablestartcallback as a place to calculate startdate and offset, use bits 17-30 of p1 to store offset. In cmdsettimetablestart set the start date and v->timetable_start_ticksoffset, which i later use in updatevehicldetimetable when the timetablestartdate is set. Am i on right track here?
17:39:53  <planetmaker> who then speak in abbreviations only
17:39:59  <TomyLobo> the nature of his mistake (b/p, swapping letters) might also hint at dyslexia
17:40:08  <TomyLobo> mistakes*
17:40:44  <planetmaker> eh?
17:41:03  <Zuu> I didn't even notice he had some swapped letters :-p
17:41:13  <TomyLobo> dyslexic!
17:41:14  <TomyLobo> :D
17:41:58  <Zuu> While I haven't been diagnosed with it, it would not surprise me. :-)
17:42:35  <Yexo> "whrer", "qustion", "fiund" <- neither of those have swapped letters
17:43:05  <Yexo> it looks much more like careless typing
17:43:11  <Hirundo> deos it?
17:43:22  <planetmaker> ti seod
17:43:26  <Zuu> where -> where looks like someone doing touch-typing quickly and miss-aligning the the finger taps in time.
17:43:51  <planetmaker> where->where looks like the unity operator
17:43:55  <planetmaker> ;-)
17:43:56  <Yexo> u is next to the i, so same for fiund, and qustion just misses a letter
17:44:17  <Hirundo> as long as the frist and lsat letters are in palce, it's prefectly raedalbe
17:44:51  <planetmaker> I call 'perfectly' something else, but yes
17:44:55  <Zuu> As long as only some words are muffeled, it is not that hard to guess the missing words. :-)
17:45:14  <avdg> hirundo: from where do I know that :p
17:46:09  <CIA-2> OpenTTD: translators * r20565 /trunk/src/lang/ (15 files in 2 dirs): (log message trimmed)
17:46:09  <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:46:09  <CIA-2> OpenTTD: belarusian - 7 changes by KorneySan
17:46:09  <CIA-2> OpenTTD: simplified_chinese - 3 changes by pda1573
17:46:09  <CIA-2> OpenTTD: traditional_chinese - 5 changes by josesun
17:46:10  <CIA-2> OpenTTD: chuvash - 31 changes by mefisteron
17:46:10  <CIA-2> OpenTTD: dutch - 5 changes by habell
17:47:34  <Zuu> hmm, what is the language order of the WT3 commit messages?
17:47:48  <Zuu> Not alphabetical it seems.
17:48:00  <Rubidium> filename?
17:48:32  <Zuu> Possible.
17:49:25  <planetmaker> you miss your name there, Zuu ? ;-)
17:49:47  <Zuu> hehe
17:50:06  <Zuu> Well, at least I do not get highlighted that often.
17:50:30  <Ammler> hmm, instead using the info sprite, maybe we could make a special sprite "PLEASE UPDATE" and use that, one which is really ugly and you can't continue playing
17:54:10  <glx> there's .notice for highlights ;)
17:54:45  <Ammler> anyway, it would be nice, if the "missing sprite" sprite would be a own sprite to define independently
17:55:02  <planetmaker> Ammler, which sprite do you want to mis-use for that end?
17:55:06  *** JVassie [~James@92.27.149.231] has quit [Ping timeout: 480 seconds]
17:55:16  <Ammler> none, I would make one
17:55:29  <planetmaker> Yeah, but you have to replace one :-)
17:55:30  *** fmauneko [~fmauneko@134.227.101-84.rev.gaoland.net] has joined #openttd
17:55:40  <Ammler> replace?
17:55:47  <Rubidium> and you want it to be used by e.g. dbset if you're using "more" wagons?
17:55:52  <planetmaker> how would the players otherwise see the update request?
17:56:26  <planetmaker> ah. ok, now I understand, Ammler :-)
17:56:30  <Ammler> you could make a sprite with the text "PLEASE UPDATE" for example
17:56:34  <planetmaker> Yes, that MIGHT make sense :-)
17:57:14  <planetmaker> Rubidium, I think the idea is to replace new GUI sprites by that one
17:57:35  <planetmaker> And... OpenTTD won't bork, if I define too many GUI sprites, right?
17:57:53  <Ammler> you don't have the issue with openttd trunk, as it has always the right set with it :-)
17:57:53  <Rubidium> it won't
17:57:59  *** ajmiles [~aj@78-86-188-187.zone2.bethere.co.uk] has joined #openttd
17:58:20  <planetmaker> Then the idea can be: Define one additional GUI sprite with the info "please\n update" :-)
17:58:31  <Rubidium> or a few
17:58:34  <planetmaker> yeha
17:59:06  <Ammler> planetmaker: it isn't just GUI
17:59:24  <Ammler> or is it?
17:59:33  <planetmaker> Ammler, but... other places is hard
17:59:51  <Ammler> your solution is already possible :-)
18:00:36  *** perk11 [~perk11@178.34.32.221] has quit [Read error: Connection reset by peer]
18:01:13  *** Zuu_ [~Zuu@cust-IP-11.data.tre.se] has joined #openttd
18:01:23  *** Zuu [~Zuu@80.251.192.2] has quit [Ping timeout: 480 seconds]
18:01:35  <Ammler> but the next issue will be the airport previes
18:01:49  <Ammler> which is for example a new feature
18:01:52  <Ammler> type*
18:03:31  <planetmaker> Well. Test what happens, if you now define type 17 :-)
18:03:57  <planetmaker> And test also what happens, if you define type 16 with only 1 sprite
18:04:03  <Ammler> it feels damn hackyish :-)
18:04:31  <planetmaker> Unknown features are by definition unsupported...
18:04:41  <Ammler> ?
18:05:00  *** Zuu [~Zuu@cust-IP-11.data.tre.se] has joined #openttd
18:05:24  <planetmaker> You want to supply sprites for things which are not know how they look like and how they're going to be defined
18:05:57  <planetmaker> I like the idea in principle :-)
18:07:29  <Ammler> I ticketed it
18:09:59  <Ammler> at least the good linux distros do also update the basesets, when they update openttd :-)
18:10:40  <andythenorth> evening
18:10:58  *** Zuu_ [~Zuu@cust-IP-11.data.tre.se] has quit [Ping timeout: 480 seconds]
18:11:05  *** Chris_Booth [~chatzilla@client-86-29-114-124.glfd.adsl.virginmedia.com] has joined #openttd
18:11:18  *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds]
18:11:30  *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing]
18:16:01  *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd
18:20:33  *** Chris_Booth [~chatzilla@client-86-29-114-124.glfd.adsl.virginmedia.com] has quit [Ping timeout: 480 seconds]
18:21:19  *** frosch123 [~frosch@frnk-590fdd94.pool.mediaWays.net] has joined #openttd
18:21:30  <andythenorth> anything?
18:22:48  *** tugg [~chew@94.247.168.90] has quit [Quit: leaving]
18:23:06  <andythenorth> :o Hirundo gets cookies
18:26:22  *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
18:26:48  *** lobster [~michielbi@86.89.201.189] has quit [Ping timeout: 480 seconds]
18:28:02  *** lobster [~michielbi@86.89.201.189] has joined #openttd
18:28:50  *** Devroush [~dennis@94-225-67-91.access.telenet.be] has joined #openttd
18:34:54  <Rubidium> Ammler: a major problem with simply letting OpenTTD use a sprite from "extra" is that it gets into major mayhem when that sprite does not exist; OpenTTD will crash quite hard
18:36:22  <Rubidium> which means that your "current" use base will get crashing OpenTTDs because they haven't updated the set yet
18:37:56  <Ammler> yeah, it would still need the current solution as worst case backup
18:38:19  <andythenorth> Hirundo: got some suggestions for string changes in connection with that patch
18:38:48  <andythenorth> (ships patch
18:39:28  *** rtypo [rtypo@pc54.clicknet.iasi.rdsnet.ro] has joined #openttd
18:39:33  <Rubidium> I've often thought about providing some mechanism for setting something in the .obg to tell when it's outdated, but that'll just simply fail horribly for nightlies and for openmsx/opensfx it's not needed at all
18:39:41  <Ammler> Rubidium: for the airport sprites it is too late anyway
18:40:38  <Rubidium> though... I think it would be fairly safe to assume that a certain set of sprites must exist after the base graphics set is loaded and if that is not the case a nice red error box can be shown that you need to update your graphics set
18:41:54  <Rubidium> and I think that is a more durable way that adding "ugly" untranslated sprites
18:42:31  <Ammler> and that would also work with airport preview sprites already :-)
18:42:41  <planetmaker> hm, indeed :-)
18:42:46  <Rubidium> and in theory work for 1.0.x as well
18:43:16  <planetmaker> question: when to show that? I guess at start of game only
18:43:30  <Ammler> well, when needed
18:43:49  <Ammler> I guess, the missing airport would cause only after starting a map
18:44:38  <Ammler> or will the whole extra grf be loaded on startup?
18:45:01  *** heffer [~felix@hyperion.fetzig.org] has quit [Remote host closed the connection]
18:45:01  <Rubidium> at least the sprite locations in the file will be known, so that can be used
18:45:13  *** heffer [~felix@hyperion.fetzig.org] has joined #openttd
18:45:36  <Ammler> well, it doesn't matter, what is the easiest, I would say
18:45:51  <Ammler> at least we could then blame "not reading the red box" :-)
18:47:50  <Ammler> using the sprite from openttd.grf is bad idea?
18:47:51  *** heffer [~felix@hyperion.fetzig.org] has quit [Remote host closed the connection]
18:48:07  *** heffer [~felix@2a01:4f8:100:6441:1::1] has joined #openttd
18:48:17  <Ammler> I guess so, wouldn't "force" the people to update, there might be other reasons, too
18:48:18  *** heffer [~felix@2a01:4f8:100:6441:1::1] has quit [Remote host closed the connection]
18:48:23  *** heffer [~felix@hyperion.fetzig.org] has joined #openttd
18:50:38  <VVG> Now that i actually made handling of startdate with ticks offset, it turns out my handling of edit box for entering times is broken :( dropdown works though
18:54:03  *** Zuu [~Zuu@cust-IP-11.data.tre.se] has quit [Ping timeout: 480 seconds]
19:01:34  *** TruePikachu [~chris@cpe-67-49-42-88.socal.res.rr.com] has joined #openttd
19:02:09  * TruePikachu discovered that, in DSLinux, L=Shift :D
19:03:12  <Hirundo> andythenorth: could you just post them in the topic?
19:03:20  <TruePikachu> Anyway, I'm working on a special Ro-Ro station with 10 task-oriented platforms
19:03:49  <TruePikachu> It will feed a factory
19:03:49  <V453000> show us :)
19:04:07  <TruePikachu> @me? I'm not at my computer ATM
19:04:26  *** lobster [~michielbi@86.89.201.189] has quit [Ping timeout: 480 seconds]
19:04:45  <TruePikachu> Brb, I'll post a save of a version after I'm off the can
19:05:15  *** lobster [~michielbi@86.89.201.189] has joined #openttd
19:05:55  <TruePikachu> Actually, I'll stitch screenshots
19:06:50  <TruePikachu> 4 waypoints plus Industrial Station Renewal = uberstation
19:07:29  <TruePikachu> I concluded that the terminus version wasn't working efficiently enough; it flooded with goods, causing Xrufuian to 'take some off my hands' (i.e. steal them all)
19:08:07  *** |Jeroen| [~jeroen@94-224-31-113.access.telenet.be] has quit [Quit: oO]
19:09:58  <TruePikachu> I don't like the exit ATM, it jams frequently, and requires an additional balancer
19:10:20  <TruePikachu> (as in, I need to build another balancer in the small space I have for one)
19:10:25  <andythenorth> Hirundo: np.
19:11:43  *** thvdburgt [~thvdburgt@banning.xs4all.nl] has quit [Ping timeout: 480 seconds]
19:15:05  <Rubidium> http://rbijker.net/openttd/happy_ammler.png ?
19:16:50  <TruePikachu> Lol, my computer is lagging like crazy right now
19:20:06  <avdg> :p
19:20:41  * Rubidium (cattle) prods Ammler
19:21:37  * frosch123 has the impression that the MAKEOPTS environment variable is gentoo specific
19:22:13  <Rubidium> that could very well be
19:22:39  <Ammler> Rubidium: I like it (k)
19:22:46  * planetmaker likes it, too
19:23:44  * Rubidium hides
19:23:52  <CIA-2> OpenTTD: rubidium * r20566 /trunk/src/ (lang/english.txt newgrf.cpp newgrf_config.h openttd.cpp): -Feature: happy smiles on the faces of Ammler and planetmaker
19:23:59  <avdg> :d
19:24:05  <planetmaker> loool :-)
19:26:21  * Rubidium wonders how long it takes for the tt-ms folks to wonder what the hell that feature is about
19:26:55  <avdg> hmm
19:27:12  <avdg> do they really care about commits?
19:27:22  <planetmaker> no and yes
19:27:34  <Rubidium> they have a "Neuste OpenTTD-Features" tracker, which reacts on -Feature and -Release
19:29:48  *** JVassie [~James@92.27.149.231] has joined #openttd
19:32:58  <avdg> never seen it
19:36:00  <Ammler> ./configure: line 168: generate_grf: command not found
19:36:08  <Ammler> on our server ^
19:36:13  <Ammler> no patches applied
19:37:31  <Rubidium> incomplete svn up?
19:38:13  <Rubidium> because generate_grf and generate_lang are extremely similar
19:38:14  <Ammler> yes, seems so
19:38:24  *** avdg [~Adium@78-21-57-217.access.telenet.be] has quit [Read error: Connection reset by peer]
19:38:25  <Rubidium> and generate_lang apparantly worked
19:38:36  *** avdg [~Adium@78-21-57-217.access.telenet.be] has joined #openttd
19:38:53  <Ammler> hmm, all fine, sorry
19:46:16  *** DJNekkid [~DJ___Nekk@static128-249.mimer.net] has quit [Ping timeout: 480 seconds]
19:55:13  *** DJNekkid [~DJ___Nekk@static128-249.mimer.net] has joined #openttd
19:59:50  <Wolf01> 'nighty night
19:59:54  *** Wolf01 [~wolf01@host176-238-dynamic.0-87-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.]
20:01:28  <andythenorth> Hirundo: does the ship patch actually change CC?  I have the GUI, but no CC changes..r20565
20:01:35  <andythenorth> tested with FISH and default ships
20:02:23  <Hirundo> It should, I'll take a look
20:02:52  <Ammler> the debug levels aren't saved somewhere for restart?
20:03:00  <Ammler> so also if -1 would work
20:03:05  <Ammler> it is useless
20:03:32  <Ammler> need to add it to the start command of course :-$
20:04:36  *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has joined #openttd
20:04:46  *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has quit [Quit: Leaving]
20:08:39  *** fmauneko is now known as fmauNeko
20:15:57  <CIA-2> OpenTTD: terkhen * r20567 /trunk/known-bugs.txt: -Document [FS#3966]: Add note to known-bugs about this issue.
20:20:34  <CIA-2> OpenTTD: yexo * r20568 /trunk/src/ai/api/ (ai_vehicle.cpp ai_vehicle.hpp): -Codechange: change the value of AIVehicle::VEHICLE_INVALID and use it as return value instead of ::INVALID_VEHICLE
20:27:27  *** KritiK [~Maxim@95-25-201-172.broadband.corbina.ru] has joined #openttd
20:30:40  *** HanziQ [~50fa045c@salieri.openttdcoop.org] has joined #openttd
20:30:55  *** HanziQ [~50fa045c@salieri.openttdcoop.org] has left #openttd []
20:33:20  <VVG> I'm doing something wrong. On second click on edit box ottd crashes. What may be an issue here?
20:34:08  <Rubidium> get a debug build's backtrace and we might be able to tell
20:34:09  <CIA-2> OpenTTD: rubidium * r20569 /trunk/src/timetable_cmd.cpp: -Cleanup: the change timetable command doesn't need the packed bit anymore
20:35:05  <CIA-2> OpenTTD: rubidium * r20570 /trunk/src/ (timetable_cmd.cpp timetable_gui.cpp): -Codechange: free/reserve some bits in the timetable commands to increase the vehicle pool limit
20:39:26  <CIA-2> OpenTTD: rubidium * r20571 /trunk/src/ (6 files in 2 dirs): -Codechange: free/reserve some bits in the order commands to increase the vehicle pool limit
20:40:37  <Hirundo> 1 million vehicles - sweet :)
20:41:15  <TruePikachu> Our XP Professional box here got hit vy a virus which sets random passwords on all accounts
20:41:24  <TruePikachu> s/vy/by
20:41:47  *** Zuu [Zuu@c-91f0e655.510-8-64736c10.cust.bredbandsbolaget.se] has joined #openttd
20:42:04  <VVG> 0 - 20 - is that 21 one bits?
20:42:10  <avdg> ouch :(
20:42:12  <CIA-2> OpenTTD: rubidium * r20572 /trunk/src/ (6 files in 2 dirs): -Codechange: free/reserve some bits in the wagon move command to increase the vehicle pool limit
20:44:36  <Alberth> VVG: some '20' are the number of bits
20:44:43  <Belugas> z home!
20:44:45  <Belugas> bye!
20:44:46  <Rubidium> VVG: GB(data, start, count)
20:44:47  <Alberth> bye
20:44:49  <Rubidium> night Belugas
20:44:57  <Belugas> u2 Rubidium :)
20:45:41  <CIA-2> OpenTTD: rubidium * r20573 /trunk/src/ (5 files in 2 dirs): -Codechange: free/reserve some bits in the sell vehicle command to increase the vehicle pool limit
20:48:29  *** sylf [~sylf@ip68-103-138-57.ks.ok.cox.net] has quit [Remote host closed the connection]
20:48:42  *** sylf [~sylf@ip68-103-138-57.ks.ok.cox.net] has joined #openttd
20:49:56  <VVG> I've build the debug version. Now i just crash it and look for stack trace in crash log?
20:50:39  <Rubidium> no, you run it in your debugger
20:57:49  *** VVG [~sdfkhksd@85.249.0.40] has quit [Read error: Connection reset by peer]
20:58:42  <CIA-2> OpenTTD: rubidium * r20574 /trunk/src/ (6 files in 3 dirs): -Codechange: a little over 1 million vehicles should be enough for the forseeable future
20:59:00  *** VVG [~sdfkhksd@85.249.0.40] has joined #openttd
21:00:12  <VVG> the whole system stopped responding when i used Start debugging in VC2008 :(
21:00:39  <andythenorth> Rubidium: does 1m vehicles provide enough room for ships to have smoke sprites?
21:00:40  <andythenorth> :P
21:01:01  *** TomyLobo [~foo@port-212-202-171-176.dynamic.qsc.de] has quit [Quit: A key, command, or action that tells the system to return to a previous state or stop a process.]
21:01:35  <Rubidium> andythenorth: if that's 1 million ships, then nope...
21:02:10  *** Chris_Booth [~chatzilla@client-86-29-114-124.glfd.adsl.virginmedia.com] has joined #openttd
21:02:36  *** Chris_Booth [~chatzilla@client-86-29-114-124.glfd.adsl.virginmedia.com] has quit []
21:05:01  <VVG> The thread 'Win32 Thread' (0x7b8) has exited with code 0 (0x0).
21:05:01  <VVG> First-chance exception at 0x7c812afb in openttd.exe: 0xE1212012: 0xe1212012.
21:05:01  <VVG> Unhandled exception at 0x7c812afb in openttd.exe: 0xE1212012: 0xe1212012.
21:05:12  <VVG> Is that an output that might be helpful?
21:05:40  <Rubidium> nope
21:05:49  <Rubidium> there should be a stack trace somewhere
21:06:22  *** Tennel [~Tennel@port-ip-213-211-212-60.reverse.mdcc-fun.de] has joined #openttd
21:10:48  <VVG> can't find any :(
21:13:43  <VVG> the only stack trace i can find is in crash.log
21:13:54  <VVG> in ./openttd folder
21:14:09  <Rubidium> that's all numbery, right?
21:14:44  <VVG> yeah, like that:  00000000 00000000 00000000 0012CDAC 0012E644 00000000 CCCCCCCC CCCCCCCC
21:14:44  <ccfreak2k> That's one way to put it.
21:15:55  <Rubidium> i.e. useless for us
21:16:12  <Rubidium> so... any MSVC user that can explain how to perform an OpenTTD debug?
21:16:25  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÌß]
21:18:07  <VVG> just in case, the error i get is this: Message:   String 0x6982 is invalid. You are probably using an old version of the .lng file.
21:18:36  <Rubidium> then you're messing up somewhere with the strings :)
21:18:39  <Hirundo> 'Start debugging' from the menu?
21:19:59  <VVG> i made some progress here, i got "dissasmbly window" with that type of lines "7C814D3D  mov         eax,dword ptr fs:[00000018h]"
21:20:12  <VVG> and many of them
21:20:32  <Hirundo> what version do you use?
21:20:56  <Hirundo> "the whole system stopped responding when i used Start debugging in VC2008 :(" <- you need patience :)
21:21:04  <VVG>  	openttd.exe!_output_l(_iobuf * stream=0x00000000, const char * format=0x00000000, localeinfo_struct * plocinfo=0x00000000, char * argptr=0x00000000)  Line 1161 + 0x18 bytes	C++
21:21:12  <VVG> there is also that line
21:21:31  <Rubidium> there should be a window/tab somewhere with stack trace or something
21:21:31  <VVG> VC++2008 express
21:21:49  <Hirundo> Did you try 'start debugging'? It tends to work perfectly (although slowly) for me
21:22:33  <VVG> yes, start debugging, game runs, made it crash, now trying to figure out what's where
21:23:04  <Hirundo> what did you click after the crash?
21:23:33  <VVG> Is this : 00E685CD  mov         eax,dword ptr [ebp-28h]
21:23:33  <VVG> 00E685D0  mov         dword ptr [ebp-18h],eax
21:23:33  <VVG> 00E685D3  mov         ecx,dword ptr [ebp-18h]
21:23:33  <VVG> 00E685D6  mov         dword ptr [ebp-1Ch],ecx
21:23:39  <VVG> how the stack trace looks like?
21:24:02  <VVG> Hirundo: break->show dissasmbly
21:24:15  <Hirundo> you don't need the disassembly
21:24:19  <glx> self compiled ?
21:24:45  <VVG> yes
21:24:52  <glx> 23:21:13] <VVG>      openttd.exe!_output_l(_iobuf * stream=0x00000000, const char * format=0x00000000, localeinfo_struct * plocinfo=0x00000000, char * argptr=0x00000000)  Line 1161 + 0x18 bytes    C++ <-- that's from the trace
21:26:01  <glx> call stack window
21:26:14  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has joined #openttd
21:26:17  <VVG> I select that line as stack frame and get a green arrow poiting me to: 00E685B8  add         esp,0Ch
21:26:53  <glx> started VS with openttd.sln?
21:27:47  <VVG> err, not quite
21:27:48  <glx> ho that's a system function, so it's ok to get only asm for it
21:28:03  <VVG> it asked me if i want to recover some file from previous session, to be exact
21:28:29  <VVG> but from the looks of it it opened all like it does when selsecting openttd_vs90.sln
21:28:58  <glx> paste the call stack somewhere
21:29:08  <Hirundo> Debug > Windows > Call stack
21:29:30  <VVG>  	kernel32.dll!7c812afb()
21:29:30  <VVG>  	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
21:29:30  <VVG>  	kernel32.dll!7c812afb()
21:29:30  <VVG> >	openttd.exe!_output_l(_iobuf * stream=0x00000000, const char * format=0x00000000, localeinfo_struct * plocinfo=0x00000000, char * argptr=0x00000000)  Line 1161 + 0x18 bytes	C++
21:29:41  <VVG> that's all i have in call stack window
21:29:55  <glx> weird
21:30:15  *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd []
21:30:42  <ccfreak2k> Are all four args supposed to be 0?
21:30:44  <glx> last lines should be
21:30:44  <glx> kernel32.dll!@BaseThreadInitThunk@12() + 0x12 octets
21:30:44  <glx> ntdll.dll!___RtlUserThreadStart@8() + 0x27 octets
21:30:44  <glx> ntdll.dll!__RtlUserThreadStart@8() + 0x1b octets
21:31:12  <Hirundo> What's your windows version?
21:31:15  <glx> and at least a WinMain somewhere
21:31:34  <glx> unless you are not in main thread
21:31:55  <VVG> I found the thread secection window just now
21:32:10  <VVG> those 4 lines are from Main thread
21:34:31  <VVG> there is also this output from one of the Worker thread: http://pastebin.ca/1920344
21:34:50  <glx> [23:05:09] <VVG> Unhandled exception at 0x7c812afb in openttd.exe: 0xE1212012: 0xe1212012. <-- anyway that's usually an assert ;)
21:34:56  *** Tennel [~Tennel@port-ip-213-211-212-60.reverse.mdcc-fun.de] has quit [Quit: Verlassend]
21:35:12  <glx> ERROR is our stuff
21:35:53  <glx> the pastebin one is for sound
21:36:15  <VVG> it's the only other thread that has openttd.exe in it
21:36:34  <VVG> others all ntdll, kernel, and some other dlls
21:38:10  <VVG> glx: mind that this is a patched version
21:38:36  <glx> patched or not, it's the same for MSVC ;)
21:39:03  <glx> but when it crashes it should just go to the crash location
21:40:06  <glx> unless you forced it to continue
21:40:30  <VVG> i'll try again
21:40:53  <glx> because 0xE1212012 is an assert
21:41:47  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has quit [Read error: Connection reset by peer]
21:41:52  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has joined #openttd
21:42:04  <VVG> okay, start debugging->ottd crash, now i have a choice between break and continue
21:42:10  <glx> break
21:42:15  <glx> always break ;)
21:42:46  <VVG> There is no sourcode avaible for current location, OK/SHOW dissasebmly
21:43:23  <glx> not important, but check the call stack
21:44:31  <glx> you should have abort(), error() and the failing line
21:45:18  * Rubidium is so happy it's easier in Linux to get someone to get a stack trace :)
21:45:33  <glx> it's easy in MSVC too
21:45:52  <VVG> where should i have them?
21:46:01  <glx> in call stack window
21:46:04  <VVG> call stack looks the same, for example again this line: >	openttd.exe!_output_l(_iobuf * stream=0x00000000, const char * format=0x00000000, localeinfo_struct * plocinfo=0x00000000, char * argptr=0x00000000)  Line 1161 + 0x18 bytes	C++
21:48:10  <VVG> if that is of any help to you, ottd crashes on second mouse click on edit box of mine
21:49:04  <glx> put the patch somewhere
21:49:14  <glx> will be easier
21:50:32  <SpComb> .crt
21:52:02  <VVG> http://rapidshare.com/files/413957866/vtrltmsstm-20523.patch
21:52:34  <VVG> the stuff for edit box is in date_gui.cpp
21:53:34  <VVG> as i wasn't sure, how relevant other stuff might be, i made a diff with all stuf i changed
21:55:13  <glx> next time patch from root, not from src ;)
21:56:08  <VVG> why? src is the only thing changed
21:57:05  <glx> because it's better to do it from root, just in case
22:00:49  *** KouDy [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
22:02:24  <VVG> that edit box is one the 2 base functionality things left to work out and it seems it's beyoud me to make it by copypasting stuff from other places :)
22:03:39  *** [alt]buster [~Combuster@82-171-220-59.ip.telfort.nl] has joined #openttd
22:03:48  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has quit [Read error: Connection reset by peer]
22:03:48  *** [alt]buster is now known as [com]buster
22:03:49  *** bryjen [~bryjen@63.147.94.149] has quit [Quit: Quit]
22:04:30  *** sylf [~sylf@ip68-103-138-57.ks.ok.cox.net] has quit [Read error: Connection reset by peer]
22:06:43  <CIA-2> OpenTTD: rubidium * r20575 /trunk/src/ai/ai_gui.cpp: -Fix [FS#4059] (r20542): reloading of companies did load another AI
22:06:43  *** sylf [~sylf@ip68-103-138-57.ks.ok.cox.net] has joined #openttd
22:08:11  <glx> VVG: does it compile for you ?
22:08:18  *** llugo [~lugo@mgdb-4db8de05.pool.mediaWays.net] has joined #openttd
22:08:31  *** smatz_ [~smatz@231.146.broadband11.iol.cz] has joined #openttd
22:09:21  <glx> +inline Time64 DateToTimeNonCapped(Date date, DateFract fract = 0) {
22:09:21  <glx> +    return int64 time_since_year_zero = (date * DAY_TICKS + fract);
22:09:21  <glx> +}
22:09:21  <glx> ^^ that's wrong for my MSVC
22:10:03  <VVG> hm
22:12:07  <VVG> eh
22:12:36  <VVG> it's different here, how come there is such a line in patch?
22:13:20  <glx> it's in date.cpp
22:13:30  *** sylf [~sylf@ip68-103-138-57.ks.ok.cox.net] has quit [Read error: Connection reset by peer]
22:14:13  <Rubidium> because you've given the wrong / not-up-to-date version?
22:14:29  <VVG> i just compiled it, looks ok
22:14:51  <VVG> i found that line, that's a leftover from trying different things, it shouln't be there at all
22:15:22  *** lugo [~lugo@mgdb-4db8c12f.pool.mediaWays.net] has quit [Ping timeout: 480 seconds]
22:15:48  <VVG> i totally forgot about that when i got distracted by other things :(
22:16:43  <VVG> anyway, it happily compiled with those lines there
22:17:21  *** DDR [~chatzilla@66.183.117.37] has joined #openttd
22:17:52  <VVG> date.cpp should not have anything after last OnNewYear
22:18:25  <glx> http://pastebin.ca/1920365 <-- I get that (the weird thing is the missing file btw, looks like svn up somehow failed)
22:19:18  <VVG> wait a sec, i'll post a more proper version
22:19:30  <VVG> compiling it atm to check it runs :)
22:19:53  *** sylf [~sylf@ip68-103-138-57.ks.ok.cox.net] has joined #openttd
22:20:25  <glx> of course svn up failed (I ran it in src because of you ;) )
22:21:34  <VVG> sorry about that :)
22:22:06  <VVG> http://rapidshare.com/files/413962713/vtrltmsstm-20523.patch
22:22:35  <VVG> there, without those lines in date.cpp, compiles fine, runs, crashes fine when forced to :)
22:23:51  <VVG> what version of MSVC do you have that it complained previosly?
22:23:59  <glx> 2008
22:24:07  <VVG> express?
22:24:10  <glx> yes
22:24:27  <glx> with windows SDK 7.1
22:24:41  *** Progman [~progman@p57A1D39F.dip.t-dialin.net] has quit [Remote host closed the connection]
22:24:49  <VVG> don't ahve that i think
22:25:02  <glx> was compiling for x64
22:25:25  *** [alt]buster [~Combuster@82-171-220-59.ip.telfort.nl] has joined #openttd
22:25:30  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has quit [Read error: Connection reset by peer]
22:25:32  *** [alt]buster is now known as [com]buster
22:26:04  <VVG> mine didn't complain a bit about those lines ;(
22:33:44  <glx> ok compiled (finally)
22:35:58  <VVG> set interaction->show timetable in to hhmm or hhmmss to get the settime dialog when setting timetable start date, that where the edit box that crashes is
22:38:14  <glx> in a running game ?
22:39:29  <VVG> yeah
22:39:30  *** nicfer [~nicfer@190.50.12.214] has joined #openttd
22:41:21  <VVG> one thing i should have mention long ago - i have no understanding of how edit box actually works, what i have there is bits copypasted from other places in ottd code
22:41:47  <glx> I get a "String is invalid message"
22:43:11  <glx>         error("String 0x%X is invalid. You are probably using an old version of the .lng file.\n", string); <-- this one
22:43:26  <VVG> yeah, that one
22:46:18  <VVG> i cant make any sense out of it
22:46:42  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has quit [Read error: Connection reset by peer]
22:47:10  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has joined #openttd
22:48:12  *** perk11 [~perk11@85.175.248.31] has joined #openttd
22:53:11  <glx> it's {WHITE}{STRING} resolving to {STRING} resolving to 0xb3c81 which is not a valid string
22:54:08  <glx> it crashes opening the OSK
22:54:44  <glx> http://pastebin.ca/1920386 <-- call stack
22:56:30  <VVG> it's uncomprenhensible for me
22:57:51  <VVG> NWidget(WWT_EDITBOX, COLOUR_WHITE is this the case here? the STR_JUST_STRING doesn't have any color codes
22:58:51  *** perk111 [~perk11@94.233.231.169] has joined #openttd
22:59:35  <TruePikachu> ^^ If that is where the error is, no closing )
22:59:36  <VVG> resolving to 0xb3c81 which is not a valid string <-- what is that?
22:59:49  <Rubidium> the STR_JUST_STRING of WWT_EDITBOX seems/feels wrong
22:59:54  <Terkhen> good night
23:00:09  *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has quit [Ping timeout: 480 seconds]
23:00:18  <Rubidium> good night Terkhen
23:01:07  <Rubidium> VVG: replacing the STR_JUST_STRING with STR_TIME_CAPTION might help
23:02:16  *** perk11 [~perk11@85.175.248.31] has quit [Ping timeout: 480 seconds]
23:02:43  <VVG> isnt that what's is show as name of the window?
23:03:28  <Rubidium> what is not STR_JUST_STRING is the caption of the on screen keyboard
23:03:32  <Rubidium> s/not/now/
23:04:27  <Rubidium> and as nothing sets the parameters for that string it crashes OpenTTD
23:04:36  <glx> data is the title yes
23:04:51  *** Wizzleby [~wizzleby@pool-108-2-26-106.phlapa.east.verizon.net] has quit [Remote host closed the connection]
23:05:03  <glx> not the content
23:06:40  <glx> it's just luck it sometimes work
23:08:36  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has quit [Read error: Connection reset by peer]
23:08:50  <VVG> whoa!
23:08:57  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has joined #openttd
23:09:21  <VVG> it works!
23:09:26  <VVG> thank you so much
23:11:23  *** APTX [~APTX@chello089077244008.chello.pl] has joined #openttd
23:13:37  <VVG> can't really express how happy i am now
23:14:18  *** Intexon [58675045@ircip1.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
23:14:28  *** APTX_ [~APTX@chello089077244008.chello.pl] has quit [Ping timeout: 480 seconds]
23:16:53  *** Zuu [Zuu@c-91f0e655.510-8-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds]
23:18:11  *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds]
23:19:53  *** Kurimus [Kurimus@dsl-tkubrasgw1-fe34dc00-202.dhcp.inet.fi] has quit []
23:20:39  *** bryjen [~bryjen@75.81.201.131] has joined #openttd
23:26:53  <TruePikachu> Lol @ forum - epic typo
23:27:13  <TruePikachu> "...when attacked to the train..."
23:27:53  *** perk111 [~perk11@94.233.231.169] has quit [Ping timeout: 480 seconds]
23:30:20  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
23:31:59  <Eddi|zuHause> * Rubidium wonders how long it takes for the tt-ms folks to wonder what the hell that feature is about <-- i seem to remember a discussion that nobody actually goes to the main page, so they don't usually see that feature list
23:33:05  <Rubidium> but I saw it... in OpenTTD's HTTP logs
23:34:53  <Rubidium> hitting trac every minute asking for the last 90 days worth of commits
23:39:09  <frosch123> every minute :o
23:39:36  <Rubidium> yes, getting a 0.5 MiB XML
23:40:07  <frosch123> can we somehow charge for that?
23:40:18  *** lllugo [~lugo@mgdb-4db8dbda.pool.mediaWays.net] has joined #openttd
23:41:49  *** nicfer [~nicfer@190.50.12.214] has quit [Remote host closed the connection]
23:42:28  <Rubidium> nah, he scaled back his thing after a mail claiming I didn't like it that their "ticker" costs 22 GiB a month
23:43:09  <ccfreak2k> Who is he in this context?
23:44:35  <Eddi|zuHause> http://www.tt-ms.de/impressum/ <-- one of these, presumably
23:45:43  <Rubidium> oh, sorry: s/he/He/
23:48:03  *** llugo [~lugo@mgdb-4db8de05.pool.mediaWays.net] has quit [Ping timeout: 480 seconds]
23:49:05  *** ecke [~ecke@188.75.128.2] has joined #openttd
23:50:47  *** [alt]buster [~Combuster@82-171-220-59.ip.telfort.nl] has joined #openttd
23:50:47  *** [com]buster [~Combuster@82-171-220-59.ip.telfort.nl] has quit [Read error: Connection reset by peer]
23:50:51  *** [alt]buster is now known as [com]buster
23:51:29  *** Biolunar [Mahdi@blfd-4db0fcd0.pool.mediaWays.net] has quit [Quit: gn8]
23:51:41  *** Sacro_ [~ben@cpc2-mfld9-0-0-cust880.mfld.cable.virginmedia.com] has joined #openttd
23:56:10  *** ajmiles [~aj@78-86-188-187.zone2.bethere.co.uk] has quit [Read error: Connection reset by peer]
23:58:49  *** Sacro [~ben@cpc2-mfld9-0-0-cust880.mfld.cable.virginmedia.com] has quit [Ping timeout: 480 seconds]
23:59:54  *** Sacro_ [~ben@cpc2-mfld9-0-0-cust880.mfld.cable.virginmedia.com] has quit [Ping timeout: 480 seconds]

Powered by YARRSTE version: svn-trunk