Times are UTC Toggle Colours
00:01:12 *** Azrael- [~azraeluk@cpc4-papw2-0-0-cust778.cmbg.cable.ntl.com] has quit [Read error: Connection reset by peer] 00:03:41 *** Svish [~Svish@84.20.108.54] has quit [Quit: Quit] 00:06:27 *** Svish [~Svish@84.20.108.54] has joined #openttd 00:06:31 *** Svish [~Svish@84.20.108.54] has quit [] 00:07:54 *** Svish [~Svish@84.20.108.54] has joined #openttd 00:10:03 *** orudge` [~orudge@189.87.115.33] has quit [Ping timeout: 480 seconds] 00:20:08 *** Antigon [~Poly@p54B45DDC.dip.t-dialin.net] has joined #openttd 00:21:34 *** orudge` [~orudge@189.71.107.217] has joined #openttd 00:21:35 *** mode/#openttd [+o orudge`] by ChanServ 00:22:01 *** Antigon [~Poly@p54B45DDC.dip.t-dialin.net] has quit [] 00:27:27 *** Polygon [~Poly@p54B4535C.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 00:31:09 *** Illegal_Alien [~Illegal_A@77.163.150.18] has quit [Read error: Connection reset by peer] 00:36:25 *** Svish [~Svish@84.20.108.54] has quit [Quit: Quit] 00:39:29 <`Fuco``> is there any way to disable trains turning around when the path is blocked? this is super annoying when train waiting on PBS signal turns around and is still saying "waiting for free path"... and so far it never turned back to the original direction 00:39:58 <`Fuco``> so they just sit there blocking the entire line 00:41:18 <`Fuco``> i use reversed PBS as a penalty, and they turn around on the very same spot, they actually have a "right oriented" signal in the way. That might be the problem. 00:41:35 <`Fuco``> If so there should be introduced some other "penalty" for pathfinder, so this can be avoided 00:42:01 <`Fuco``> (..penalty, and IF they...) 00:43:43 <Coco-Banana-Man> try searching for "wait_oneway_signal" (or also for "wait_twoway_signal", if you want it on two-way-signals too!) and replace the number by 255 00:43:53 <Coco-Banana-Man> this should work IIRC 00:43:59 *** KenjiE20|LT [~Kenji@host86-171-52-206.range86-171.btcentralplus.com] has joined #openttd 00:44:44 *** KenjiE20 [~KenjiE20@92.22.27.101] has quit [Quit: WeeChat 0.3.0-rc2] 00:45:01 *** Chruker [~no@0x5da34ce4.vjnqu1.dynamic.dsl.tele.dk] has quit [] 00:45:14 <Coco-Banana-Man> erm.. 00:45:23 <Coco-Banana-Man> on openttd.cfg of course... ^^ 00:47:19 *** orudge` [~orudge@189.71.107.217] has quit [Ping timeout: 480 seconds] 00:48:19 <`Fuco``> thanks ill try 00:48:47 <Coco-Banana-Man> ok, got to go to bed now. 00:48:50 <Coco-Banana-Man> Good night! 00:48:52 <`Fuco``> night 00:49:10 *** Coco-Banana-Man [~Stephan.D@p5B2DE2F6.dip.t-dialin.net] has quit [Quit: Raubgut ist vom Umtausch ausgeschlossen!] 00:56:03 *** Lakie` [~Lakie@91.84.251.149] has joined #openttd 01:03:28 *** Lakie [~Lakie@91.84.251.149] has quit [Ping timeout: 480 seconds] 01:15:12 *** orudge` [~orudge@189.87.115.33] has joined #openttd 01:15:15 *** mode/#openttd [+o orudge`] by ChanServ 01:17:44 *** oskari89 [oskari89@dsl-kpobrasgw1-ff7cc100-243.dhcp.inet.fi] has quit [Quit: Utm Aœ - Aja 35] 01:17:55 *** Chrill [~chrischri@80.216.60.117] has quit [] 01:32:31 *** Pygma [~quassel@88.151.27.234] has joined #openttd 01:44:29 <Pygma> Hey 02:11:27 *** KenjiE20|LT [~Kenji@host86-171-52-206.range86-171.btcentralplus.com] has quit [Quit: Leaving] 02:15:19 *** orudge` [~orudge@189.87.115.33] has quit [Ping timeout: 480 seconds] 02:30:14 *** glx [glx@2a01:e35:2f59:c7c0:e411:f86c:b8d6:8424] has quit [Quit: bye] 03:04:23 *** Brianetta [~brian@client-86-0-123-9.nrth.adsl.virgin.net] has quit [Ping timeout: 480 seconds] 03:09:02 *** TinoDidriksen [~tino@port432.ds1-od.adsl.cybercity.dk] has quit [Ping timeout: 480 seconds] 03:09:53 *** Tekky [~chatzilla@DSL01.83.171.176.10.ip-pool.NEFkom.net] has quit [Ping timeout: 480 seconds] 03:12:39 *** TinoDidriksen [~tino@port432.ds1-od.adsl.cybercity.dk] has joined #openttd 03:25:14 *** Lakie` [~Lakie@91.84.251.149] has quit [Quit: Sleep.] 03:38:52 *** TinoDidriksen [~tino@port432.ds1-od.adsl.cybercity.dk] has quit [Ping timeout: 480 seconds] 03:42:57 *** TinoDidriksen [~tino@port432.ds1-od.adsl.cybercity.dk] has joined #openttd 03:48:21 *** `Fuco`` [~dota.keys@ip-105.imafexbb.sk] has quit [Ping timeout: 480 seconds] 03:56:52 *** Pygma [~quassel@88.151.27.234] has quit [Remote host closed the connection] 04:39:20 *** reldred [~reldred@115.131.198.88] has joined #openttd 04:56:33 *** ecke [~ecke@213.195.202.11] has joined #openttd 05:51:21 *** roboboy [3aad2910@webchat.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 06:25:06 *** roboboy [3aad2910@webchat.mibbit.com] has joined #openttd 06:29:46 *** ecke [~ecke@213.195.202.11] has quit [Quit: ecke] 06:36:14 *** Netsplit resistance.oftc.net <-> larich.oftc.net quits: eleusis, @Belugas, CIA-2 06:41:35 *** Netsplit over, joins: @Belugas, eleusis, CIA-2 06:42:57 *** mode/#openttd [+v Belugas] by ChanServ 06:55:32 *** _ln [~lanurmi@dyn-xdsl-83-150-113-243.nebulazone.fi] has joined #openttd 06:59:21 *** FR^2 [~frquadrat@frquadrat.de] has joined #openttd 07:13:51 *** Tekky [~chatzilla@DSL01.83.171.166.194.ip-pool.NEFkom.net] has joined #openttd 07:44:16 *** maristo [~maristo@host217-114-156-151.pppoe.mark-itt.net] has joined #openttd 07:48:55 *** Azrael- [~azraeluk@cpc4-papw2-0-0-cust778.cmbg.cable.ntl.com] has joined #openttd 07:50:33 *** FR^2 [~frquadrat@frquadrat.de] has quit [Quit: Der Worte sind genug gewechselt, lasst mich auch endlich Taten sehn!] 07:54:38 *** Svish [~Svish@84.20.108.54] has joined #openttd 07:58:30 *** Svish [~Svish@84.20.108.54] has quit [Quit: Leaving] 07:59:05 *** Progman [~progman@p57A1FB6E.dip.t-dialin.net] has joined #openttd 08:01:08 *** ecke [~ecke@213.195.202.11] has joined #openttd 08:05:30 *** |Jeroen| [~jeroen@94-224-31-113.access.telenet.be] has joined #openttd 08:10:17 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 08:12:55 *** FR^2 [~frquadrat@frquadrat.de] has joined #openttd 08:19:25 *** ecke [~ecke@213.195.202.11] has quit [Quit: ecke] 08:55:02 *** frosch123 [~frosch@frnk-590fd0be.pool.einsundeins.de] has joined #openttd 09:16:05 *** Coco-Banana-Man [~Stephan.D@p5B2DE113.dip.t-dialin.net] has joined #openttd 09:25:33 *** tokai [~tokai@p54B80F44.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 09:27:44 *** tokai [~tokai@p54B81973.dip0.t-ipconnect.de] has joined #openttd 09:27:47 *** mode/#openttd [+v tokai] by ChanServ 09:36:21 *** yorick [~Yorick@s55924da0.adsl.wanadoo.nl] has joined #openttd 09:39:39 *** fonsinchen [~alve@BAEcab6.bae.pppool.de] has joined #openttd 09:40:42 *** ecke [~ecke@213.195.202.11] has joined #openttd 09:43:38 *** George3 [~George@212.113.107.216] has joined #openttd 09:49:37 *** George [~George@212.113.107.216] has quit [Ping timeout: 480 seconds] 10:05:55 *** Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has quit [Remote host closed the connection] 10:10:54 *** Exl [~myself@cp1224652-a.roemd1.lb.home.nl] has joined #openttd 10:13:58 *** Tekky_ [~chatzilla@DSL01.83.171.166.194.ip-pool.NEFkom.net] has joined #openttd 10:13:58 *** Tekky [~chatzilla@DSL01.83.171.166.194.ip-pool.NEFkom.net] has quit [Read error: Connection reset by peer] 10:14:00 *** Tekky_ is now known as Tekky 10:21:36 *** Progman [~progman@p57A1FB6E.dip.t-dialin.net] has quit [Remote host closed the connection] 10:26:16 *** dfox [~dfox@r11jn246.net.upc.cz] has quit [Ping timeout: 480 seconds] 10:51:29 *** KenjiE20 [~KenjiE20@92.22.58.177] has joined #openttd 10:53:05 *** thingwath [~thingwath@88.83.164.57] has quit [Quit: It's all over.] 11:01:19 *** Polygon [~Poly@p54B4647B.dip.t-dialin.net] has joined #openttd 11:04:15 *** |Jeroen| [~jeroen@94-224-31-113.access.telenet.be] has quit [Quit: oO] 11:06:05 *** fjb [~frank@p5485EF8F.dip.t-dialin.net] has joined #openttd 11:06:11 <fjb> Hello 11:11:12 *** DJ-Burtybob [burtybob@92.22.75.113] has joined #openttd 11:17:13 *** Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has joined #openttd 11:25:41 *** Wolfensteijn [~Wolfenste@dhcp-077-250-089-252.chello.nl] has quit [Quit: Changing server] 11:26:05 *** wolfy [~Wolfenste@dhcp-077-250-089-252.chello.nl] has joined #openttd 11:27:10 *** Chruker [~no@0x5da34ce4.vjnqu1.dynamic.dsl.tele.dk] has joined #openttd 11:28:39 *** jolteon [~Jolteon@5acb3168.bb.sky.com] has joined #openttd 11:28:42 <jolteon> hai, quick question. 11:28:56 <jolteon> How can I stop my trains reporting as being "lost", when actually it's just in a station loading? 11:29:05 *** jolteon is now known as Jolteon 11:29:37 <Chruker> Are you sure its not just old messages that have been waiting in the queue to be displayed? 11:29:50 *** dfox [~dfox@r11jn246.net.upc.cz] has joined #openttd 11:31:46 <Jolteon> Chruker: I have no idea, i'm yet to find a button that limits the length of how long messages will wait before being displayed. 11:31:53 <Jolteon> (or a way to tell how long they've been waiting) 11:32:26 *** [com]buster [~Eternal@cust-03-55bf402e.adsl.scarlet.nl] has joined #openttd 11:32:36 <[com]buster> Hi all 11:32:47 <Chruker> If you want to disable or reduce some messages, you can change their settings by clicking the News Paper icon and then Message Settings. 11:33:42 <Jolteon> hmm, i'll try reducing some to off then 11:33:44 <Jolteon> cheers 11:35:15 <[com]buster> Some tech question 11:35:24 <[com]buster> what things are done every 4 days? 11:35:32 <[com]buster> or at least computed? 11:35:36 *** Jolteon [~Jolteon@5acb3168.bb.sky.com] has left #openttd [] 11:35:54 *** Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has quit [Remote host closed the connection] 11:35:55 *** Polygon [~Poly@p54B4647B.dip.t-dialin.net] has quit [Quit: Verlassend] 11:36:53 <[com]buster> I notice framedrops exactly at each 4-day interval 11:38:21 <SmatZ> aliens? 11:38:43 <SmatZ> ah, fRamedrops 11:38:49 <SmatZ> 255-ticks? 11:38:58 <SmatZ> err, 250-ticks 11:39:14 <[com]buster> if that many ticks correspond to ~4 game days 11:39:24 <SmatZ> roughly, yes 11:39:30 <SmatZ> station "big tick" iirc 11:39:35 <SmatZ> and probably other newgrf stuff 11:39:45 <SmatZ> recomputing station acceptance 11:41:37 * [com]buster thinks that last one's killing the current openttdcoop game :/ 11:42:25 <SmatZ> it's lagging every 3,5 days? 11:43:21 <[com]buster> it is 11:45:08 <[com]buster> Was kindof looking for a way to alleviate the problem 11:45:19 <[com]buster> *cough*multithread*cough* 11:45:29 <yorick> beware! 11:46:10 <[com]buster> Don't worry, I'm not spamming tickets for MP support 11:46:12 <[com]buster> yet :) 11:46:21 <yorick> how would it help? 11:46:56 <[com]buster> yorick: I take the map data does not change over the cargo acceptance cycle, no? 11:47:24 <SmatZ> [com]buster: anyone suggesting that should be muted until he comes with a working multithreaded OTTD :-p 11:47:39 <SmatZ> and not only 1 thread rendering + 1 thread computations 11:47:43 <[com]buster> I've got some mental plans for multithreaded pathfinding 11:48:13 <SmatZ> if performance doesn't die on synchronisation :) 11:48:48 <yorick> [com]buster: but industries affect cargo acceptance 11:49:03 <yorick> and also -> multiplayer sync 11:49:21 <[com]buster> Determinism, yes yes yes 11:49:26 <yorick> you'd still have to wait for the cargo acceptance calculations to finished 11:49:31 <[com]buster> I heard all the arguments at least once :) 11:49:41 <yorick> just once? 11:50:08 <[com]buster> at least</quote> 11:50:41 <[com]buster> I've been spammed to death with most obvious ones 11:51:01 <[com]buster> You dev's are a little too predictable in that regard :) 11:51:22 <SmatZ> yorick's not a dev! :-D 11:51:57 <SmatZ> not OTTD dev that is 11:51:58 <[com]buster> He acts like one, close enough :) 11:52:07 <yorick> :-( 11:52:09 <SmatZ> hehe 11:52:28 <yorick> are you comparing me with thát? 11:53:26 *** Singaporekid [~notme@cm6.psi140.maxonline.com.sg] has joined #openttd 11:53:35 <[com]buster> I think the bottom line is 11:53:53 <[com]buster> you've been brainwashed enough by the ones who *are* devs 11:54:16 <[com]buster> to voice their opinion in their place ;) 11:56:43 *** glx [glx@2a01:e35:2f59:c7c0:2198:8523:b023:2c79] has joined #openttd 11:56:46 *** mode/#openttd [+v glx] by ChanServ 11:57:46 <SmatZ> [com]buster: don't say you disagree with these statements 11:57:58 <SmatZ> unless you rework a lot of game logic 12:00:29 * [com]buster resists the urge to bounce back the design argument 12:02:15 <Chruker> Need more parralllelllelism in openttd :-) 12:02:33 <yorick> Chruker: you spelled it rong! 12:02:35 <Chruker> And no, I wont just run 4 openttd games at once :-) 12:02:52 <[com]buster> on a quadcore 12:02:59 <[com]buster> that's currently the best thing to do :) 12:03:03 <Chruker> hehe 12:03:04 <[com]buster> er 12:03:06 <[com]buster> :( 12:03:09 <frosch123> hmm, if we do the threading discussion daily, I vote for reactivating babyottd, so it can do the discussion on its own after a week 12:03:27 <SmatZ> hehe 12:03:37 *** Dred_furst [~Dred@user-544348a3.lns6-c7.dsl.pol.co.uk] has joined #openttd 12:03:48 <[com]buster> Threading *will* come by every other day as it is a hot issue 12:03:54 <[com]buster> independent of openttd 12:04:19 <SmatZ> k 12:04:59 <[com]buster> SmatZ, Am I right that the pathfinder will only bother with *other* trains for a limited distance 12:05:16 <[com]buster> like red signal penalties and block/pbs groups 12:05:48 <[com]buster> and that after some distance, other trains' decision don't affect other trains? 12:06:05 <yorick> they could affect them indirectly 12:06:08 <yorick> using the other trains 12:06:54 <glx> and pathfinding MUST be deterministic, ie same result at the same time on all clients 12:08:05 <[com]buster> well 12:08:26 <[com]buster> at least you can start with running ship/rv pathfinding on a different core than train pathfinding 12:08:42 <glx> rv are linked to trains 12:08:44 <yorick> bool NeedResort() --> bool NeedReSort() :) 12:08:52 <yorick> ship pathfinding 12:08:58 <yorick> they don't affect eachother at all 12:09:11 <yorick> but ship pathfinding first needs to be better 12:09:24 <[com]buster> but ship pathfinding of itself is a disjunct operation 12:09:43 <[com]buster> I just wonder, in what way is RV pathfinding linked to rail pathfinding 12:09:49 <SmatZ> feel free :) 12:09:59 <frosch123> [com]buster: level crossings 12:10:04 <SmatZ> [com]buster: train path reservation -> level crossings get barred 12:10:17 <glx> and possible crashes on crossing 12:10:55 <[com]buster> and occupied crossings = PF penalty? 12:11:51 <[com]buster> or at least, different from non-occupied crossings? 12:12:59 <[com]buster> otherwise, the pathfinding is still disjunct 12:14:19 * yorick thinks you could start with gui 12:15:13 <[com]buster> SmatZ once said he already did that 12:15:17 *** Biolunar [mahdi@blfd-4db01d42.pool.einsundeins.de] has joined #openttd 12:15:30 <[com]buster> to something like 10% gain? no? 12:15:38 <SmatZ> yeah 12:15:42 <SmatZ> but -10% for uniproc 12:15:54 <yorick> oh, yes, SmatZ did everything 12:15:59 <yorick> SmatZ did 3d openttd 12:16:01 <yorick> :) 12:16:18 <frosch123> [com]buster: you cannot do the pathfinding without the movement just afterwards, and you cannot move roadvehicles if you don't know whether they need to stop resp. they crash 12:17:07 <[com]buster> @yorick: That's one for the fictive get_logical_cpu_count() function :) 12:17:22 <[com]buster> which you'd need for this kind of stuff anyway 12:18:19 <yorick> or go remove everything gui from dedicated servers 12:18:39 <frosch123> excellent suggestion 12:18:59 <yorick> compiles twice as fast, might be twice as small 12:19:03 <[com]buster> IMO 12:19:04 <yorick> and might be not faster 12:19:13 <[com]buster> dedicated servers should not be faster than the clients 12:19:18 <[com]buster> gets everybody kicked 12:19:30 <yorick> no 12:19:36 <frosch123> yorick: you know about the "dedicated" video driver? 12:19:38 <yorick> there's some tick limit :) 12:19:51 <yorick> frosch123: that's the one that displays absolutely nothing? 12:19:55 <[com]buster> yorick: ? 12:20:01 <yorick> [com]buster: ? 12:20:09 <[com]buster> [14:19] <yorick> there's some tick limit :) <- ? 12:20:12 <SmatZ> [com]buster: ? 12:20:17 <Ammler> [com]buster: why not ask intel to make more powerful single cpus? 12:20:22 <SmatZ> they are faster when the game is huge 12:20:25 <Ammler> might be easier 12:20:31 <SmatZ> because they don't have to draw anything 12:20:34 <SmatZ> but that's clear to you :) 12:20:50 <yorick> SmatZ: but the gui part is still compiled 12:21:07 <yorick> if you manage to separate, it could be a bit easier to thread 12:21:08 <frosch123> Ammler: why not wait until everyone uses multicore with some posix-sufficient os. might be easier 12:21:19 <[com]buster> Ammler, TBH it is not about what Intel will do, but what we will do 12:21:30 <[com]buster> and we all know its going towards more and more and more cores 12:21:36 <[com]buster> and not clock cycles 12:21:40 <Ammler> hehe ";-)" 12:22:41 <[com]buster> btw, xxx's processor lead is only temporary, as history has proved a few times too often 12:23:00 <[com]buster> anyway 12:24:06 <[com]buster> yorick: how does your system fix the fact that a server can do more pathfinding per unit of time than a client, and once the client's capaccity is reached, it will fall behind in ticks and be kicked from the game? 12:24:34 <yorick> [com]buster: that's the clients fault 12:25:05 <SmatZ> [com]buster: actually, when client's late, it doesn't do rendering 12:25:15 <SmatZ> until it "catches up" with the server 12:25:16 <[com]buster> I know 12:25:23 <[com]buster> [14:19] <[com]buster> dedicated servers should not be faster than the clients 12:25:24 <[com]buster> [14:19] <[com]buster> gets everybody kicked 12:25:35 <SmatZ> or don't play such huge maps :) 12:25:38 <yorick> so you slow down your servers so the clients can catch up 12:25:40 <yorick> you're strange 12:25:41 <yorick> :-) 12:25:51 <[com]buster> more like 12:25:52 <yorick> just put your server on a limit then 12:26:01 <[com]buster> allow anybody without the latest Pentium 1337 to play 12:26:15 <yorick> they can play 12:26:28 <[com]buster> no they can't 12:26:33 <yorick> until they can't keep up with (72?) ticks per second 12:26:57 <[com]buster> I think SmatZ knows the problem that maps get stopped because *nobody* is able to keep up with the server 12:27:13 *** MizardX [MizardX@h-28-236.A159.priv.bahnhof.se] has quit [Read error: Connection reset by peer] 12:27:44 <yorick> then you have a too big game 12:27:45 *** MizardX [MizardX@h-28-236.A159.priv.bahnhof.se] has joined #openttd 12:27:48 <yorick> or a too small client 12:28:27 <[com]buster> A dev's disclaimer 12:28:40 <[com]buster> I thought you were fans of usability, no? 'o.o' 12:28:51 <yorick> I'm not a dev! :-D 12:29:06 <SmatZ> [com]buster: yeah, I know that problem 12:29:12 <[com]buster> [13:51] <[com]buster> He acts like one, close enough :) 12:29:13 <yorick> first separate, then thread 12:29:13 <SmatZ> but I have better CPU than the server 12:29:17 <SmatZ> so I don't mind 12:29:18 <SmatZ> :-p 12:29:20 <SmatZ> joking ;) 12:29:30 <SmatZ> but well, if someone joins with 500MHz CPU 12:29:36 <SmatZ> you can't slow down the server because of that 12:29:43 <SmatZ> and make it unplayable for everyone 12:29:45 <yorick> so every dev that agrees I act like one, raise hand 12:30:06 <[com]buster> unfair when the majority's asleep 12:30:19 <yorick> the majority is asleep at 14:30? 12:30:31 <[com]buster> I see only SmatZ talk... 12:30:34 <fonsinchen> I'm wondering how to debug desyncs. I can catch the debug message from network.cpp and I can see that probably different amounts of random numbers have been pulled in the games involved but it's somewhat difficult to see where. What is the usual procedure of finding out about that? 12:30:45 <yorick> :-D 12:30:57 <yorick> fonsinchen: isn't that on the wiki? 12:30:58 <TrueBrain> fonsinchen: a lot of time 12:31:29 <yorick> http://wiki.openttd.org/OpenTTDDevBlackBook/Network/Desync_debugging 12:32:10 * [com]buster goes to make a ticket for slowing down game speed by a certain amount 12:32:44 <fonsinchen> thanks 12:33:06 *** Akoz [potatoe@216-135-35.oke1-bras10.adsl.tele2.no] has quit [Ping timeout: 480 seconds] 12:33:18 * TrueBrain wonders how playable a game would be at 1 tick per second .. just to keep up with my 50 MHz machine :) 12:33:46 <[com]buster> Exxagerating is an art 12:33:54 <[com]buster> and an annoying one too :( 12:34:06 <yorick> SmatZ: what would be the best way to convert newgrf_gui.cpp:ShowNewGRFInfo to a function that prints the bounding box of the text, without avoiding code duplication? :) 12:34:35 <[com]buster> I mean like, slow down a Xeon to a P4's speed 12:34:42 <yorick> erm, with avoiding code duplication* 12:34:44 <yorick> heh 12:34:54 <TrueBrain> ghehe @ yorick 12:36:54 *** fonsinchen [~alve@BAEcab6.bae.pppool.de] has quit [Remote host closed the connection] 12:38:27 <TrueBrain> planetmaker: nice, that image in your signature whichs shows last commit of OpenGFX 12:39:34 <yorick> TrueBrain: I have one with world airliner set :-) 12:42:25 <frosch123> except it is not the latest commit 12:42:34 <TrueBrain> :'( 12:42:52 <frosch123> mabye the latest done by him :) 12:43:19 <yorick> no, planetmakers should be the latest 12:43:42 <yorick> or the rss feed is borken 12:44:05 <frosch123> yeah, somehow the opengfx log mixes commits and flysprayish-activities 12:44:27 <yorick> frosch123: you're looking at the activity log 12:44:39 <yorick> the rss feed is generated by hgweb 12:44:44 <yorick> but mine is better :-) 12:44:49 <TrueBrain> mine is bigger 12:45:04 <frosch123> are you friends of sirkoz? 12:45:25 <yorick> no? 12:45:45 <Ammler> frosch123: everyone is :-) 12:46:12 <frosch123> did he already release BetterGfx ss 12:46:19 <frosch123> s/ss/?/ 12:46:44 <frosch123> can i somehow install a permanent search-replace to what i type? 12:47:23 <yorick> you can try to pipe to sed 12:47:25 <yorick> :-) 12:48:02 *** KritiK [~Maxim@78-106-215-137.broadband.corbina.ru] has joined #openttd 12:48:30 *** fjb [~frank@p5485EF8F.dip.t-dialin.net] has quit [Remote host closed the connection] 12:48:35 <TrueBrain> frosch123: /ignore? 12:49:20 <frosch123> but that can only do "/frosch/ D" 12:49:57 <TrueBrain> sounds to me like a permanent search-replace action ;) 12:50:45 <frosch123> and it works, doesn't it ? 12:50:50 <TrueBrain> no idea, never tried :p 12:51:00 <TrueBrain> I wish there was a good IDE for linux for C projects .... blegh 12:51:02 <frosch123> just not inside worssds 12:51:03 <yorick> I did, it doens't :-) 12:51:09 <TrueBrain> credit to MS, MSVC really works as IDE :( 12:51:19 <yorick> s/ns/sn/ :( 12:51:32 <TrueBrain> you all suck! 12:51:44 <Ammler> TrueBrain: didn't you try KDevelop? - So, it failed? 12:51:51 <yorick> who needs IDEs 12:51:57 <TrueBrain> kdevelop is one crappy piece of software :( 12:52:03 <TrueBrain> maybe it got better in the last year ... 12:52:09 <frosch123> ok, forgot to tick "regular expression", works also in words 12:53:11 <Ammler> TrueBrain: netbeans? 12:53:33 <TrueBrain> never tried it .. I stopped reading after 'Java' 12:53:39 <TrueBrain> maybe I should put that issue aside .. 12:54:07 <frosch123> TrueBrain: define "good IDE" 12:54:14 <Ammler> well, I use those tools too less to give you serious comments ;-) 12:54:32 <TrueBrain> frosch123: well .. for one, it should be able to compile what I tell him to 12:54:40 <TrueBrain> it should allow you to open files in a normal way 12:54:43 <TrueBrain> have project support 12:54:49 <TrueBrain> and don't crash on random intervals 12:55:04 <TrueBrain> (which means kdevelop, kate, kwrite, vi already fail) 12:55:09 <frosch123> project support :/ never saw a worst invention 12:55:12 <Ammler> TrueBrain: which KDE did you use as you tested those? 12:55:21 <TrueBrain> I don't use KDE 12:55:23 <TrueBrain> :p 12:55:31 <TrueBrain> but KDE-libs 3.something and 4.0 and now 4.1 12:55:37 <TrueBrain> or even 4.2 ... hmm .. 12:55:44 <TrueBrain> I will give kdevelop another spin soon 12:55:51 <Ammler> will 4.2 is the first useable kde3 12:55:54 <Ammler> 4* 12:55:57 <TrueBrain> frosch123: I work on too many projects to work without it .. I need to open a project and get some files open I left open :p 12:56:09 <Ammler> and well* :-P 12:56:51 <frosch123> TrueBrain: I work on too many projects to set up project files for all of them :p 12:57:01 <TrueBrain> frosch123: well 'setting up' is a big word 12:57:09 <TrueBrain> I just want to start a new project, give a dir, and be done with it :p 12:57:21 <TrueBrain> it is mostly for dir + open files :p I dislike browsing ... 12:57:34 <Ammler> all, what kdevelop does, but well, I work too less with it. 12:57:47 <TrueBrain> what kdevelop does, yes, but thatone kept on crashing :p 12:58:03 <Ammler> I used it with kde3.5 12:58:18 <Ammler> which is imo, very stable. 12:58:21 <yorick> ooh, GetStringHeight :-) 12:58:25 <frosch123> hmm, kdevelop. kdevelop's grepping is weird, I prefer kate's 12:58:39 <TrueBrain> frosch123: yup, you are absolutely right 12:58:43 <TrueBrain> just kate fucks up from time to time 12:58:50 <TrueBrain> telling me there are no matches 12:58:54 <dihedral> which woman does not fuck up? 12:58:54 <TrueBrain> while I am standing near one 12:58:55 <frosch123> never did for me 12:59:02 <TrueBrain> happens a bit too often lately :( 12:59:16 <TrueBrain> dihedral: women fuck, not fuck up (or so I hope) 12:59:25 <dihedral> they do both? 12:59:27 <dihedral> :-P 12:59:35 <TrueBrain> you know nothing about the first :p 12:59:37 <TrueBrain> MWHAHAHAHAHA 12:59:49 <dihedral> that's what YOU think ^^ 12:59:53 <frosch123> just you cannot help kate's grepping to ignore .svn resp. I don't know how 13:00:02 <frosch123> s/help/tell/ :s 13:00:08 <TrueBrain> I guess I can give netbeans a god .. 13:00:26 *** Akoz [potatoe@216-135-35.oke1-bras10.adsl.tele2.no] has joined #openttd 13:00:31 *** OwenS [~oshepherd@host86-164-125-58.range86-164.btcentralplus.com] has joined #openttd 13:00:59 <frosch123> oh, and a good ide shall start up in less than a second 13:01:05 <TrueBrain> that too 13:01:21 <frosch123> on my machine :p 13:01:52 <TrueBrain> 113 packets needed to install netbeans ..... 13:01:59 <TrueBrain> wtf? 13:02:15 <frosch123> so it will likely not start up in less than a second :p 13:02:24 <TrueBrain> Gentoo wants to compile from source 13:02:29 <TrueBrain> not always the best way ;) 13:02:39 <frosch123> but it works :) 13:02:51 <frosch123> no problems like missing shared libs or so 13:02:55 <TrueBrain> very true 13:02:58 <TrueBrain> but 113 packets? 13:03:11 <TrueBrain> and the download of netbeans website doesn't work :p 13:03:22 *** Tekky_ [~chatzilla@DSL01.83.171.176.171.ip-pool.NEFkom.net] has joined #openttd 13:03:23 <OwenS> About the only good "IDE's" I've found on Linux are QtCreator (Great - but kinda Qt only ;-)) and KATE + Makefile (Not an IDE :P ) 13:03:38 <TrueBrain> OwenS: I use the latter currently ... annoys the hell out of me 13:03:49 <TrueBrain> (mostly because going to an error takes too much time and effort) 13:03:51 <TrueBrain> su 13:03:53 <TrueBrain> lol 13:03:55 <TrueBrain> wrong window ;) 13:04:30 <OwenS> lol. I've got to say, I wish Linux/Unix apps would put one asterisk out when you enter the first character of your password to confirm you're typing into the right window 13:05:24 <frosch123> are you using fwv2 with immediate focus stealing via mouse? 13:05:40 <TrueBrain> I hate those desktops! HELL NO! :) 13:05:42 <frosch123> hmm, it is called fvwm, right? 13:05:58 <TrueBrain> I use xfce4, which has one nasty thing, that you can operate a window with your mouse, without giving it the focus 13:06:03 <TrueBrain> it confuses me from time to time 13:06:16 <TrueBrain> adding that I have 2 (wide) screens, doesn't help in detecting where the blue bar is :p 13:07:45 <OwenS> No; KDE4, no immediate focus stealing. Doesn't help though since Yakuake doesn't have a nice highlight bar :p 13:07:51 <frosch123> [15:06] <TrueBrain> I hate those desktops! HELL NO! :) <- I like the description in the kde preferences; something like "quite useless and stupid, but we want to support everything, which other wm can do" 13:08:53 <TrueBrain> xfce4 has one 'nasty' thing with autofocus: when the firefox auto-search thing drops, it focuses the window 13:08:56 *** Tekky [~chatzilla@DSL01.83.171.166.194.ip-pool.NEFkom.net] has quit [Ping timeout: 480 seconds] 13:09:04 *** Tekky_ is now known as Tekky 13:09:04 <TrueBrain> while typing, it casues the auto-search to popup again 13:09:10 <TrueBrain> and you can keep on going like that for a few minutes :p 13:10:57 <OwenS> I've never been a fan of GTK... probably related to the very evil file chooser 13:13:00 * frosch123 dislikes words starting with "g". you never know whether they refer to gnu, gnome, gimp, ... 13:13:23 <OwenS> At least as of late KDE has stopped naming everything KName 13:13:42 <frosch123> well, some also use Kame 13:13:59 <OwenS> Though avoiding starting them with g (Looking at you, GwenView) would avoid making me think they were Gnome apps 13:15:26 <TrueBrain> I hate most that software that puts 'open' before open source projects 13:15:31 <TrueBrain> so very annoying 13:15:49 *** Zahl [~Zahl@f051052012.adsl.alicedsl.de] has joined #openttd 13:16:38 <frosch123> yeah, only stuff starting with # or ! is worse 13:16:50 *** reldred [~reldred@115.131.198.88] has quit [Read error: Connection reset by peer] 13:18:38 <Ammler> frosch123: like amaroK 13:19:33 <frosch123> s/: like/ likes/ 13:19:38 *** planetmaker [~pm@vs241204.vserver.de] has left #openttd [] 13:20:00 *** FR^2 [~frquadrat@frquadrat.de] has quit [Quit: Der Worte sind genug gewechselt, lasst mich auch endlich Taten sehn!] 13:20:53 <Ammler> which "music manager" do the GNOME people use? 13:21:36 <frosch123> I use it as player, not as manager. music managers are as bad as project files 13:23:10 *** Fuco [~dota.keys@ip-105.imafexbb.sk] has joined #openttd 13:26:21 <TrueBrain> on that, I agree :) 13:26:56 <Ammler> well, I use it to clean up file system, too. 13:27:34 <frosch123> can it also clean up /usr/portage/distfiles ? 13:28:11 <Ammler> don't have that in my media share :-) 13:28:41 <OwenS> I use Amarok as a media manager. I quite often have to retag files :p 13:29:17 <TrueBrain> retagging via Picard (or rather, my automated scripts) via MusicBrainz 13:29:25 <TrueBrain> no human interaction requires .. and no stupid player 13:30:36 <Ammler> well, I like it how it has always the lyrics and wikipedia and such around, specially if you listen something new. 13:31:02 <OwenS> Which Amarok version? 13:31:42 <SmatZ> my keyboard stopped working 13:31:44 <SmatZ> so I hit it 13:31:47 <SmatZ> several times 13:31:50 <Ammler> oh, I am kinda behind, 1.4 13:31:51 <SmatZ> now my hands are bleeding 13:31:55 <SmatZ> and it's still not working :-/ 13:32:05 <TrueBrain> SmatZ: then ... why are you typing? 13:32:20 <OwenS> Ammler: Heh, at least you didn't have to fiddle with the Amarok 2.0 alphas :p 13:32:34 <SmatZ> TrueBrain: different computer :) 13:32:53 <Ammler> openttd is one of the rarly used alphas here. 13:33:32 <Ammler> is used kde3.5 until a month back. 13:33:39 <Ammler> !s/is/I/ 13:33:45 <OwenS> I upgraded to KDE4 when it went RC, and tried out the Amarok 2 alphas (and reverted to 1.4 because the ywere immensely buggy) 13:33:52 <Ammler> frosch123: I could use your autoSed too ;-) 13:34:17 <SmatZ> hmm should I upgrade to KDE4 at computers with ~300MHz and ~GeForce2 ? 13:34:29 <OwenS> KDE4 is lighter than KDE3 in my experience 13:34:32 <frosch123> Ammler: I found a sed-like setting in konversation :) 13:35:34 <OwenS> But, heh, the oldest computer here is a 2.5Ghz P4 with GF4MX (AKA GeForce2 rebadged edition). And I don't know what it's like on that since it's my windows box :p 13:36:19 <SmatZ> hehe 13:36:40 <TrueBrain> SmatZ: distcc 13:36:56 <OwenS> Though my current box kinda is behind the times. 13:37:00 <SmatZ> TrueBrain: problem isn't compiling, I can let emerge run for weeks :) 13:37:16 <TrueBrain> ah, 'should I', misread you there :) 13:37:18 <TrueBrain> my mistake ;) 13:37:36 <SmatZ> :) 13:37:40 <OwenS> I don't understand how people have the patience to use Gento with all it's compiling :p 13:37:52 <TrueBrain> the stability you get in return .... 13:38:05 <OwenS> I've not noticed any lack of stability :p 13:38:40 * frosch123 likes it default settings 13:38:56 <TrueBrain> that too .. I like the vim settings too :) 13:39:00 <TrueBrain> I can't work with debian vim :( 13:39:01 <OwenS> Heck, last time i experienced unstability it was nVIDIA who were to blame :p 13:39:01 <frosch123> (as weird as that may sound for a gentoo system) 13:39:17 <SmatZ> :) 13:39:24 *** planetmaker [~pm@vs241204.vserver.de] has joined #openttd 13:39:28 <SmatZ> I like Win+D works in Gentoo's KDE ;) 13:39:30 <TrueBrain> welcome back planetmaker 13:39:35 <SmatZ> hello planetmaker! 13:39:39 <planetmaker> hi :-) 13:39:50 <SmatZ> where have you been? 13:40:06 <planetmaker> running to not be exposed to a thunderstorm :-) 13:40:15 <planetmaker> And I hit the wrong keys when closing chatzilla. 13:40:21 <planetmaker> Closing this channel instead of the app 13:40:29 <SmatZ> :) 13:40:34 <OwenS> Haha. I recently got stuck in a thunderstorm for an hour or two :p 13:40:39 <frosch123> he, Ammler: don't molest my client 13:41:55 <Ammler> well 13:42:31 <Ammler> I wondered, if you already updated to KDE4 Konversation 13:42:52 <OwenS> Ooh, they finally ported it? 13:42:56 <frosch123> i'm on 3.5.10 13:43:08 <Ammler> OwenS: still alpha 13:43:08 <TrueBrain> 3.5.10 here too 13:43:11 * SmatZ molested Ammler's client 13:43:16 <SmatZ> 3.5.10 here 13:43:41 <OwenS> I can't stand 3.5 any more... Alt+F2 is useless in it, and theres no program menu search :p 13:43:56 <OwenS> Oh yeah, and it consumes unholy quantities of RAM 13:44:10 <SmatZ> what should Alt+F2 do? 13:44:16 <Ammler> app start 13:44:26 <Ammler> or <-> 13:44:35 <OwenS> In KDE3, brings up the run window; in KDE4, brings up a much more useful launcher 13:44:42 <SmatZ> hehe 13:44:46 <SmatZ> enjoy :) 13:44:57 <OwenS> I'm too used to Alt+F2ing and F12ing 13:45:03 <SmatZ> I am using K menu for everything 13:45:12 <SmatZ> or I run Konsole and start apps from there 13:45:30 <OwenS> Flaah. Starting Konsole takes too long. Yakuake FTW 13:45:31 <planetmaker> hm... 3.5.9 here :-P 13:45:47 <SmatZ> outdated planetmaker is outdated :-p 13:45:56 <planetmaker> :-) 13:46:12 <frosch123> it takes some time to make a planet 13:46:19 <planetmaker> haha :-) 13:46:34 <planetmaker> indeed. But it's a matter of perspective ;) 13:46:42 <planetmaker> Could be considered short, too :-P 13:46:49 <OwenS> From about 4.1 KDE4 has been very usable; from 4.2 it's had feature parity with 3.5; heck, it was usable from 4.0 13:46:51 <SmatZ> :-) 13:47:18 <planetmaker> my KDE is of limited stability :S 13:47:20 <SmatZ> OwenS: for me, having GF8600GT on my main computer, it wasn't usable 13:47:42 <SmatZ> I even installed it, but those 5fps made me quickly get back to 3.5 13:47:50 <SmatZ> it's most likely fixed now :) 13:48:27 <OwenS> I believe Alt+F12 or something like that turned off compositing 13:48:44 <OwenS> As of now, though, it should run on pretty much any GPU - and if it doesn't, will disable compositing 13:49:26 <SmatZ> I searched for solution, but failed... I everytime found only questions regarding 8600's performance 13:49:46 <SmatZ> or maybe compositing couldn't be disabled those times... 13:50:08 <OwenS> I still don't understand why nVIDIA haven't heard of underclocking in their Linux drivers though 13:51:02 <SmatZ> OwenS: seems to work for me 13:51:09 <SmatZ> with Coolbits 13:51:26 <OwenS> Coolbits? 13:51:29 <SmatZ> it doesn't have multiple power profiles though 13:51:56 <OwenS> I would pretty much like the drivers to not run my original 8800GTS heat generator at full speed while sitting at the desktop without me having to intervene though :p 13:52:01 <SmatZ> http://www.phoronix.com/scan.php?page=article&item=197&num=2 13:59:37 <[com]buster> Jotted down a prototye for *efficient* multithreaded pathfinding 14:00:08 <[com]buster> People interested in an openoffice draw doc? 14:00:45 <planetmaker> always. 14:01:03 <[com]buster> a sec while I upload it 14:01:04 <OwenS> Is it OpenOffice or is there an OpenDocument spec for that now? 14:01:08 <planetmaker> though it's a rather peculiar format. You could export pdf. 14:01:24 <OwenS> And if there is an OpenDocument spec for it - why not just use SVG?! 14:01:24 <[com]buster> and blow up filesize? :) 14:01:33 <[com]buster> just quit using MS office 14:01:35 <[com]buster> :p 14:01:41 <OwenS> PDFs aren't big... 14:01:53 <planetmaker> indeed. pdfs are actually ziped (or something) 14:02:18 <yorick> or just use a plain text file 14:02:20 <OwenS> LZW I think 14:02:27 <yorick> with linux line endings :-) 14:02:32 *** Pygma [~quassel@88.151.27.234] has joined #openttd 14:02:36 <yorick> and uft-8 text 14:02:40 <yorick> utf* 14:03:05 <[com]buster> does openoffice _draw_ mean anything? 14:03:11 <[com]buster> utf-8 lol 14:03:52 <[com]buster> http://dimensionalrift.homelinux.net/combuster/Multithreaded%20Pathfinder.odg 14:04:54 <OwenS> Wow, that document remi9nded me that OpenOffice still hasn't heard of Anti Aliasing... 14:05:06 <[com]buster> It does when you export ;) 14:05:12 *** HerzogDeXtEr1 [~Flex@89.246.196.53] has joined #openttd 14:05:25 *** Zorn [~zorn@e177238039.adsl.alicedsl.de] has joined #openttd 14:05:38 <[com]buster> but that was not the point 14:05:40 <OwenS> Thats more an aspect of the format viewer though 14:05:55 <[com]buster> http://dimensionalrift.homelinux.net/combuster/Multithreaded%20Pathfinder.pdf <- pdf for the whores 14:06:15 <OwenS> Okular's a much better viewer anyway :p 14:06:32 <yorick> it's slow 14:06:33 <yorick> ew 14:06:34 <yorick> slew 14:06:35 <OwenS> Though your server is slow :p 14:06:51 <[com]buster> that's not it 14:07:05 <[com]buster> my bittorrent is using 90% of the uplink :/ 14:07:18 <yorick> but your dependencies have dependencies 14:07:23 <yorick> and they have dependencies 14:07:26 <yorick> and they have dependencies 14:07:30 <yorick> and signal lookahead 14:07:35 <yorick> and 14:07:36 <yorick> and 14:07:37 <yorick> and 14:07:40 <[com]buster> Read dammit 14:08:10 * yorick would like to see a working non-desyncing faster patch 14:09:04 <[com]buster> the thing is determinism 14:09:10 <planetmaker> combuster: but pathfinding is not a local thing but a global one... 14:09:18 <[com]buster> so? 14:09:24 <OwenS> [com]buster: So's mine incidentally 14:09:29 <[com]buster> it is network analysis 14:09:50 <yorick> show me a faster, working, non-desyncing example 14:10:08 <OwenS> [com]buster: But I tend to serve files off my fast, in a data center server :p 14:10:12 <[com]buster> it works by redefining the order in which units are pathfinded 14:10:18 <[com]buster> that order is determinate 14:10:27 <yorick> then show me... 14:10:37 <[com]buster> it does however delay dependencies in a huge way 14:10:52 * yorick will not listen until there's a working patch 14:10:55 <yorick> :-) 14:11:05 * [com]buster breaks out the slapping rod and looks sternly at yorick 14:11:14 <[com]buster> \slap ftw 14:11:17 <TrueBrain> [com]buster: what do you mean with: "trains can be multithreaded"? 14:11:20 * yorick gets a slapping shield 14:11:32 *** HerzogDeXtEr [~Flex@89.246.170.191] has quit [Ping timeout: 480 seconds] 14:11:46 <[com]buster> the execution of the pathfinder on each train 14:12:01 <yorick> wouldn't 4 be dependent on 5 via train 6 then 14:12:07 <TrueBrain> as long as you block the rest of the game, you should be fine 14:12:21 <[com]buster> true 14:12:22 <Akoz> you give each train a thread, and then make the layout of the tracks so that when the trains runs without breakdowns they weave a sweater 14:12:34 <TrueBrain> I only doubt that hte extra CPU required to do this calculation would result in any positive gain by this solution 14:12:36 <[com]buster> you will still have to sync the start and end of the pathfinder 14:12:50 <yorick> better implement better caching 14:12:52 <[com]buster> true, do not attempt on singlecores 14:13:00 <TrueBrain> (remember that PF is only done when a train enters a junction) 14:13:25 <TrueBrain> so net-gain of such implementation would be below zero (even for multicores I am afraid) for games with a low amount of trains 14:13:27 <TrueBrain> say .. 300 or so 14:13:29 <yorick> yapf isn't fast enough for you 14:13:49 <Akoz> truebrain: make it trigger when you have >1k trains then :) 14:13:52 <TrueBrain> so I don't think this is worth any effort of implementing :( 14:13:58 <[com]buster> Truebrain: and block/pbs signals? 14:13:59 <planetmaker> TrueBrain, for low amounts possibly. But for low amounts it's not important as they don't hit any limits anyway 14:14:08 <yorick> also, TrueBrain, you know people are complaining about the speed of the squirrel pathfinder? :-P 14:14:11 <TrueBrain> planetmaker: the point is you make low amounts SLOWER 14:14:21 <planetmaker> TrueBrain, yes, I understood that 14:14:40 <[com]buster> TrueBrain: good optmisation improves the worst case 14:14:42 <planetmaker> My point is: for low amounts a bit slow down is not harmful 14:14:47 <TrueBrain> in all scenarios it is very bad to make a whole game slower, to gain speed in some exsentric situation ;) 14:14:55 <planetmaker> Because no computer limit is reached there 14:15:04 <TrueBrain> planetmaker: bad policy :) 14:15:14 <TrueBrain> what Akoz suggests would be the only 'sane' thing to do 14:15:19 <TrueBrain> but then I say: not worth the effort :) 14:15:27 <planetmaker> TrueBrain, well, depends, IMO 14:15:38 <Akoz> as long as someone else is doing the effort part it's worth it to me! 14:15:38 <TrueBrain> just stating my opinion, feel free to implement it :) 14:15:55 <TrueBrain> I would never keep any of you to implement anything :) 14:15:59 <planetmaker> the question is what you want: a game which runs everywhere but can be scaled to bigger numbers (with some relative penalty for lower numbers) 14:16:07 <planetmaker> or a game which is optimized for low numbers 14:16:11 <Akoz> I had to disbandon a game the other day cause my computer couldn't keep the pace when we got 1500 trains 14:16:15 <TrueBrain> just 2 conditions hold for any patch: it shouldn't make the whole game slower to make a few situations faster, and the code should be good ;) 14:16:31 <TrueBrain> planetmaker: 'low' numbers in this case are 95% of the users ;) 14:16:52 <SmatZ> [com]buster: every access to "volatile area" needs to be synchronised, and that's very expensive 14:16:56 <TrueBrain> above the 1000 trains, the game starts to stall on an average pc ;) 14:17:00 <yorick> pathfinding is quite not the good thing to optimize, methinks 14:17:02 <planetmaker> TrueBrain, but the questions are: 14:17:13 <[com]buster> SmatZ: read on 14:17:20 <planetmaker> a) how big is the slow down relative and absolute 14:17:21 <yorick> better optimize stations and acceptance 14:17:29 <TrueBrain> [com]buster: I considered implementing OSPF in OpenTTD ;) 14:17:30 <planetmaker> b) which vehicle number is approx break even 14:17:30 <yorick> yes, go optimize station ticks 14:17:40 <TrueBrain> planetmaker: didn't I say that? :) 14:17:46 <planetmaker> c) is that vehicle number sufficiently low to justify that change 14:17:53 <TrueBrain> and that my guess is that it wouldn't hold :) 14:17:59 <planetmaker> c) is actually the interesting question 14:18:01 <OwenS> TrueBrain: Mmmh, OSPF 14:18:14 <TrueBrain> [16:13] <TrueBrain> so net-gain of such implementation would be below zero (even for multicores I am afraid) for games with a low amount of trains 14:18:15 <TrueBrain> [16:13] <TrueBrain> say .. 300 or so 14:18:23 <TrueBrain> planetmaker: exactly what I say (give or take a few words) :) 14:18:37 <TrueBrain> but .. implement it, and we can benchmark it ;) 14:18:39 <Ammler> he, maybe you could make one core per company, but then, it will have troubles with sharing patch. 14:18:44 *** Tekky_ [~chatzilla@DSL01.83.171.172.18.ip-pool.NEFkom.net] has joined #openttd 14:19:07 <Ammler> and it wouldn't help coop 14:19:11 <[com]buster> The approach turns trains into batches 14:19:12 <TrueBrain> OwenS: in theory it is a nice idea :) Just the problem is that most TT users make junctions in a way that gives a OSPF junction every 3 tiles :p 14:19:32 <[com]buster> you only need to synchronize for a single batch 14:19:46 <OwenS> TrueBrain: Perhaps BGP then? :p 14:19:51 <TrueBrain> OwenS: LOL! No :p 14:20:17 <[com]buster> :) 14:20:37 <[com]buster> The thing I was considering 14:21:07 <[com]buster> part of the network analysis is also used by YAPF 14:22:40 <TrueBrain> [com]buster: isn't calculating such depgraph (on every track layout change) not really expensive? 14:23:06 <[com]buster> it is limited 14:23:37 <[com]buster> any change can only modify atmost three objects 14:23:48 <TrueBrain> mostly I wonder about merging the nodes 14:23:55 <TrueBrain> page 2, first image, 6 nodes becomes 1 node in the second image 14:24:17 <TrueBrain> keeping in mind TT players are not that good in designing good junctions, how do you know it is 1 single node? 14:24:49 <[com]buster> it is one node because the area of effect reaches the other nodes in the junction 14:24:52 *** Tekky [~chatzilla@DSL01.83.171.176.171.ip-pool.NEFkom.net] has quit [Ping timeout: 480 seconds] 14:24:56 *** Tekky_ is now known as Tekky 14:25:07 <TrueBrain> huh? 14:25:12 <[com]buster> i.e. smaller than the signal lookahead 14:25:26 <[com]buster> the one thing the algorithm does 14:25:28 <TrueBrain> in that cast the most left node should be merged with it too :p 14:25:36 <TrueBrain> cast = case :p 14:25:46 *** Progman [~progman@p57A1FB6E.dip.t-dialin.net] has joined #openttd 14:25:53 <[com]buster> the signal lookahead is too large indeed 14:26:02 <[com]buster> iirc it was 10 14:26:07 <[com]buster> but the point is, 14:26:16 <SmatZ> 10 is max, 2 is default i think 14:27:22 *** Tekky_ [~chatzilla@DSL01.83.171.148.61.ip-pool.NEFkom.net] has joined #openttd 14:29:21 <TrueBrain> [com]buster: somehow I doubt you can merge such nodes in a correct way. But even without merging, you can create dep-graphs, so not a real issue I guess 14:29:33 <TrueBrain> [com]buster: might be an interesting project to start, but I think the outcome is depressing .. 14:29:52 <[com]buster> Even if you do stupid graphing 14:29:54 <TrueBrain> (like a few devs also tried making the whole map access in a thread-way ... outcome was depressing too .. mostly for single cores :p) 14:30:37 *** DephNet[Paul] [~paul@host86-140-69-225.range86-140.btcentralplus.com] has quit [Ping timeout: 480 seconds] 14:30:56 <OwenS> I wonder if it would be less depressing if the number of workers was limited to the number of cores and they cycled between protothreads as needed 14:31:16 <TrueBrain> I sure hope you won't create more cores than the user owns 14:31:50 *** orudge` [~orudge@189.87.115.33] has joined #openttd 14:31:52 *** mode/#openttd [+o orudge`] by ChanServ 14:31:52 *** sdafsdf [~here@78-105-102-180.zone3.bethere.co.uk] has joined #openttd 14:31:52 *** LadyHawk [~here@78-105-102-180.zone3.bethere.co.uk] has quit [Read error: Connection reset by peer] 14:32:02 *** sdafsdf is now known as LadyHawk 14:32:10 *** [alt]buster [~Eternal@cust-03-55bf402e.adsl.scarlet.nl] has joined #openttd 14:32:57 *** Tekky [~chatzilla@DSL01.83.171.172.18.ip-pool.NEFkom.net] has quit [Ping timeout: 480 seconds] 14:33:02 *** maristo [~maristo@host217-114-156-151.pppoe.mark-itt.net] has quit [Remote host closed the connection] 14:33:04 *** Tekky_ is now known as Tekky 14:33:22 <[alt]buster> Bottom line of the approach is 14:33:32 <[alt]buster> divide the net in N pieces 14:34:13 <[alt]buster> group the vehicles that affect only one piece, and execute the pieces concurrently 14:34:37 <[alt]buster> then execute the vehicles crossing multiple pieces 14:35:11 <[alt]buster> for all I care, use the X coordinate 14:36:17 <TrueBrain> even if this would work, and say you normally can run 3000 trains, you now would be able to run, what, 4000? Maybe 5000? Does it really differ, I wonder :) 14:37:25 <TrueBrain> nevertheless, I think the idea is nice and nifty :) 14:38:47 *** [com]buster [~Eternal@cust-03-55bf402e.adsl.scarlet.nl] has quit [Ping timeout: 480 seconds] 14:38:48 *** [alt]buster is now known as [com]buster 14:39:32 <[com]buster> Glad someone appreciates it :) 14:39:48 <TrueBrain> I like thinking out-of-the-box (which this is) 14:40:35 *** orudge` [~orudge@189.87.115.33] has quit [] 14:41:29 <TrueBrain> hmm .. you made me think about my OSPF idea again .. if you can merge nodes like that in a normal way, you can run OSPF (which will be much faster, as it isn't really a pathfinder in the tradional sense) 14:41:43 <TrueBrain> it just consumes more memory :p 14:42:17 <[com]buster> Its like the improved pathfinder, no? 14:42:45 <[com]buster> in running time that is 14:43:11 <TrueBrain> OSPF is a network technoligy 14:43:18 <TrueBrain> how routers inside your ISP know and find eachother 14:43:23 <OwenS> Open Shortest Path First 14:43:38 <OwenS> [ExactlyWhatItSaysOnTheTin] 14:43:39 <TrueBrain> basicly, each node knows which nodes to send data to reach a given destination the fastest 14:43:46 <TrueBrain> when a link utilizes, other links would be used 14:43:52 *** orudge` [~orudge@189.87.115.33] has joined #openttd 14:43:55 *** mode/#openttd [+o orudge`] by ChanServ 14:44:06 <TrueBrain> (although in netwoking, the latter only happens when you utilize, say, above 80% or so) 14:44:08 <OwenS> Crap I'm TVTroping on IRC... 14:44:48 <TrueBrain> in the old days on the internet each node had a big table about all other nodes, so a n^n table 14:44:51 <TrueBrain> OSPF is a tiny bit more clever ;) 14:46:17 <OwenS> Yeah. Intra-ISP, OSPF; Inter-ISP, eBGP 14:47:09 <TrueBrain> one can also consider BGP, but BGP is a push protocol, where OSPF is a flood protocol 14:47:51 <OwenS> On the plus side, OpenTTD wouldn't have flapping problems 14:48:00 <TrueBrain> lol 14:48:27 <TrueBrain> no unannounced dead links 14:48:32 <TrueBrain> lovely, a perfect world 14:49:19 <OwenS> No AS 7007 incidents 14:49:24 <TrueBrain> hahahahah 14:51:35 *** DJ-Burtybob [burtybob@92.22.75.113] has quit [Ping timeout: 480 seconds] 14:58:18 * yorick is surprised there is no SmallVector::iterator 15:07:34 <Eddi|zuHause> hm... anyone has a quick idea how i can check if a line ends with "A", the next two lines end with "B" and "C"? 15:07:52 <Eddi|zuHause> preferably a single command line ;) 15:08:02 *** Singaporekid [~notme@cm6.psi140.maxonline.com.sg] has quit [Quit: Leaving] 15:10:06 <TrueBrain> pff, netbeans still isn't installed :( 15:10:47 <frosch123> /A$/ { N; /B$/ { N; /C$/ { p; .... plus some branches and deletes 15:17:44 *** TheMask96 [martijn@greed.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 15:18:40 <CIA-2> OpenTTD: alberth * r16878 /trunk/src/rail_gui.cpp: -Codechange: Let WWT_LABEL widgets do the drawing rather than OnPaint. 15:19:16 *** JFBelugas [~jfranc@ip-45.40.99.216.dsl-cust.ca.inter.net] has joined #openttd 15:22:58 *** TheMask96 [martijn@greed.vhost.ne2000.nl] has joined #openttd 15:23:58 <TrueBrain> finally, netbeans is installed ... but I am already done with my project of the day :( 15:25:28 <TrueBrain> I think I forgot to install C++ for netbeans .... :s 15:29:28 <Eddi|zuHause> the translation system of Civ4 is stupid... 15:29:41 <TrueBrain> why? 15:30:35 <Eddi|zuHause> if you introduce a <TEXT>-tag, you must give strings for all translations (english, french, german, italian, spanish). if you forget one of the languages for one of the text-tags, all strings will be blank 15:30:56 <TrueBrain> isn't civ4 paid software, which has the translation for you? 15:31:13 <Eddi|zuHause> yes. but it is "open source", so people can provide mods 15:31:27 <Eddi|zuHause> and these modders also must provide all translations... 15:31:31 <TrueBrain> maybe something for WT3 :p 15:31:45 * yorick is still waiting for that suggestions feature 15:31:53 <TrueBrain> happy waiting 15:32:02 <yorick> and still concerned my password is not safe on your website :-) 15:32:06 <Eddi|zuHause> if you want to implement XML-handling in WT3, feel free :) 15:32:15 <TrueBrain> no, we steal your password and hack your bankaccount 15:32:21 <TrueBrain> SHA14$abdfgw2342dfds 15:32:23 <TrueBrain> right? 15:32:30 <yorick> I have no account 15:32:32 <yorick> for that reason 15:32:39 <TrueBrain> lol 15:32:40 <yorick> haha 15:32:48 <TrueBrain> that is most likely the most stupiest reason I have ever read 15:32:57 <TrueBrain> you don't have an account, because you are afraid your password is not safe 15:33:00 <TrueBrain> .... 15:33:09 <TrueBrain> you do know you can use more than one password on the internet? 15:33:09 *** DephNet[Paul] [~paul@host86-140-69-225.range86-140.btcentralplus.com] has joined #openttd 15:33:15 <Alberth> maybe you should not have a password instead :p 15:33:34 <yorick> I'll never remember! 15:33:45 <Eddi|zuHause> anyway... now i am searching for all <text>-tags that do not have a <german>-tag 15:33:45 <TrueBrain> really yorick, you just made it to my list of most stupest user ever :p 15:33:58 <yorick> I barely remember my spotify password 15:34:05 *** DephNet[Paul] [~paul@host86-140-69-225.range86-140.btcentralplus.com] has quit [] 15:34:13 <TrueBrain> yorick: but as our website is in SVN, feel free to check how we store your password 15:34:21 <yorick> it is now? 15:34:25 *** DephNet[Paul] [~paul@host86-140-69-225.range86-140.btcentralplus.com] has joined #openttd 15:34:32 <yorick> ooh 15:34:34 <Eddi|zuHause> which are like 10 of 2000, distributed over 20 xml-files 15:34:48 <TrueBrain> but please, if you don't trust us without looking at it, don't sign up 15:34:56 <TrueBrain> and .. please never install the game again 15:35:15 <TrueBrain> Eddi|zuHause: write a script :) 15:36:29 * yorick looks at code 15:36:48 * TrueBrain writes a no-yorick-signup piece of code and commits it 15:37:20 <TrueBrain> Eddi|zuHause: I will consider Civ4 support when I write WT3.1 and release it in a more general form :) 15:37:49 *** DephNet[Paul] [~paul@host86-140-69-225.range86-140.btcentralplus.com] has quit [] 15:38:58 <yorick> hm, hashtype$salt$hash 15:39:04 <yorick> sha1 hashy 15:39:14 <yorick> and how do I know you haven't patched django 15:39:21 <TrueBrain> yorick: don't signup 15:39:23 <TrueBrain> please don't 15:39:32 <TrueBrain> I can assure you I will distribute your password over the whole web 15:39:34 <TrueBrain> hack all your accounts 15:39:41 <TrueBrain> and make your mom see that video you don't want anyone to see 15:39:44 <TrueBrain> I promise you I will 15:39:55 <yorick> NOT THE VIDEO 15:39:58 *** DephNet[Paul] [~paul@host86-140-69-225.range86-140.btcentralplus.com] has joined #openttd 15:40:55 <CIA-2> OpenTTD: alberth * r16879 /trunk/src/rail_gui.cpp: -Codechange: Use coordinates of widgets for custom rendering. 15:41:22 <TrueBrain> and again yorick, please never start the game again 15:41:25 <TrueBrain> I am sure I wrote a backdoor somewhere 15:41:28 <TrueBrain> where I could do the same 15:42:17 <yorick> OH NOES 15:45:00 <_ln> does someone know what's that place with huge satellite dishes in northern netherlands? (somewhere northwest of groningen) 15:45:33 <Alberth> westerbork? 15:45:41 <TrueBrain> 'huge'? 15:45:46 <TrueBrain> VLT, that is huge 15:46:02 <Alberth> hmm, but both are not in Groningen. 15:46:10 <TrueBrain> VLT is not even in this country :p 15:47:21 <_ln> well, not particularly close to Groningen. somewhere in the countryside. 'huge' = 2 times the height of trees near them. 15:48:10 <TrueBrain> http://www.astronomie.nl/beeldbank/30/379/westerbork_synthese_radiotelescoop.html 15:49:03 <planetmaker> _ln, not sure, but maybe it's part of the the very low frequency array... 15:49:29 <TrueBrain> that website says it is the biggest, which is a bit of a bullshit :p 15:49:45 <TrueBrain> planetmaker: VLA is in New Mexico 15:49:49 <TrueBrain> :p 15:50:00 <planetmaker> TrueBrain, not the VLA. That's radio 15:50:01 <TrueBrain> and LOFAR are 1m in height :p 15:50:05 <planetmaker> ^^ 15:50:19 <planetmaker> :-) I thought of that. The name eluded me. 15:50:42 <TrueBrain> friend of mine processed one of the first data from Berlin and back, so somehow I remember that name :p 15:50:43 <TrueBrain> http://upload.wikimedia.org/wikipedia/commons/5/56/LOFAR,_ITS_Test_Station.png 15:51:00 <planetmaker> a friend of mine works on lofar :-) 15:51:18 <TrueBrain> then they most likely met :p (he has been up and down Germany a few times :p) 15:51:21 <planetmaker> but I wasn't sure that they might have some "conventional" antennae, too 15:51:35 <planetmaker> well... he's there in the Dutch "Pampa" :-P 15:51:47 <TrueBrain> lol, up and down :p 15:52:14 <TrueBrain> either way, LOFAR has more problems launching the project than any images currently :p 15:53:10 <TrueBrain> planetmaker: LOFAR shuold get a big telescope, but as far as I know, it hasn't been built yet :) 15:53:23 <TrueBrain> it started in august last year or something 15:53:50 <_ln> hmm, Westerbork looks basically right, but its location is not consistent with my data. 15:54:02 <TrueBrain> Westerbork hasn't moved over th elast few years 15:55:07 <_ln> we basically drove from Groningen to some small town called 'Anjum', and the dishes were somewhere quite close to the latter one. 15:57:00 <planetmaker> he, yeah.... lofar is not easy to get off the ground... 15:57:29 <TrueBrain> bah, surfnet doesn't have a nice image anymore which shows the amount of traffic over their fibers .. was fun to watch :) 15:58:21 <planetmaker> :-) 15:58:35 <planetmaker> Yeah, they definitely need state of the art network technology :-) 15:58:48 <TrueBrain> (lofar goes over surfnet fiber network) 15:58:53 <planetmaker> And good real-time computers for data pre-processing 15:59:00 <CIA-2> OpenTTD: rubidium * r16880 /trunk/src/station_cmd.cpp: -Codechange: replace magic numbers with their enums and use a clearer variable name than 'flag' in the station naming function. 16:01:33 *** OwenS [~oshepherd@host86-164-125-58.range86-164.btcentralplus.com] has quit [Read error: Connection reset by peer] 16:01:58 *** OwenS [~oshepherd@host86-164-125-58.range86-164.btcentralplus.com] has joined #openttd 16:04:05 <Alberth> _ln: anjum sounds about right, I know there are a few telecom (<5 iirc) dishes there, but couldn't remember the name of the town. 16:04:46 <Alberth> westerbork has 14 iirc 16:08:11 <Akoz> what is "squirrel" in ottd? 16:08:28 <Eddi|zuHause> the ai scripting language 16:09:31 <Akoz> oh right 16:10:25 <Akoz> could someone move task 3040 to another category for me? 16:10:40 <TrueBrain> at random? 16:10:42 <TrueBrain> sure 16:11:04 <TrueBrain> better? 16:11:21 <Akoz> newgrf 16:11:22 <Akoz> hmm 16:11:28 <Akoz> dno. what do you think? :)' 16:11:30 <TrueBrain> :) Hehehe :) 16:11:35 <TrueBrain> I think you should be more specific :) 16:11:47 <Akoz> Im not sure 16:11:53 <Akoz> I guess core? 16:12:01 <Akoz> its gui 16:12:09 *** paul_ [~paul@94.76.226.86] has joined #openttd 16:12:14 <TrueBrain> GUI == Interface 16:12:16 <TrueBrain> what about you? 16:12:19 <Akoz> :p 16:12:20 <Akoz> sounds goods 16:12:28 <Akoz> *good 16:12:55 <Akoz> ty :) 16:12:59 <TrueBrain> np :) 16:13:56 *** Tekky_ [~chatzilla@DSL01.83.171.178.245.ip-pool.NEFkom.net] has joined #openttd 16:14:13 *** Tekky [~chatzilla@DSL01.83.171.148.61.ip-pool.NEFkom.net] has quit [Read error: Connection reset by peer] 16:14:23 *** Tekky_ is now known as Tekky 16:19:07 *** DephNet[Paul] [~paul@host86-140-69-225.range86-140.btcentralplus.com] has quit [Ping timeout: 480 seconds] 16:19:49 *** OwenSX [~oshepherd@host86-148-74-47.range86-148.btcentralplus.com] has joined #openttd 16:19:59 *** OwenS is now known as Guest1588 16:19:59 *** OwenSX is now known as OwenS 16:21:21 *** paul_ [~paul@94.76.226.86] has quit [Quit: Leaving] 16:21:27 *** DephNet[Paul] [~paul@94.76.226.86] has joined #openttd 16:22:17 *** Guest1588 [~oshepherd@host86-164-125-58.range86-164.btcentralplus.com] has quit [Ping timeout: 480 seconds] 16:28:46 *** orudge` [~orudge@189.87.115.33] has quit [Ping timeout: 480 seconds] 16:28:56 *** orudge` [~orudge@189.87.115.33] has joined #openttd 16:28:59 *** mode/#openttd [+o orudge`] by ChanServ 16:38:17 *** Dragoon_Jett [~JohnGalt@d67-193-154-52.home3.cgocable.net] has joined #openttd 16:39:02 *** TheCondor [~thecondor@82-169-216-227.ip.telfort.nl] has joined #openttd 16:39:03 <Dragoon_Jett> I am new to OTTD, could anyone point me to a website with a lot of custom resources for it 16:39:46 <TrueBrain> http://www.tt-forums.net 16:39:49 <TrueBrain> http://www.google.com 16:39:54 <TrueBrain> http://wiki.openttd.org 16:40:00 <Dragoon_Jett> I tried google but I am lazy 16:40:11 <Dragoon_Jett> Thanks Ill check these out 16:40:11 *** OwenS [~oshepherd@host86-148-74-47.range86-148.btcentralplus.com] has quit [Ping timeout: 480 seconds] 16:40:59 <_ln> get well soon 16:41:38 <TrueBrain> Dragoon_Jett: and welcome to OpenTTD :) 16:43:29 <Dragoon_Jett> Well im not totally new but just me and a few friends play over hamachi and we want to try a desert map with not tropical cities 16:43:38 *** OwenS [~oshepherd@host86-145-221-7.range86-145.btcentralplus.com] has joined #openttd 16:58:24 *** Progman [~progman@p57A1FB6E.dip.t-dialin.net] has quit [Remote host closed the connection] 16:58:43 <CIA-2> OpenTTD: rubidium * r16881 /trunk/src/ (47 files in 3 dirs): -Codechange: fix some naming inconsistencies w.r.t. strings used in the vehicle list GUIs. 17:07:46 *** TheStarLion [~isaac@user-54459eb5.lns1-c13.telh.dsl.pol.co.uk] has joined #openttd 17:09:42 *** TheStarLion [~isaac@user-54459eb5.lns1-c13.telh.dsl.pol.co.uk] has quit [] 17:11:58 * planetmaker just wonders: how many orders may a single vehicle have? 17:12:18 <planetmaker> I'm now at 95, but that's definitely less than half of what I need :-) 17:13:06 <TrueBrain> you know that you don't have to give it such amount of orders it needs for his whole lifetime, right? 17:13:12 <TrueBrain> it will go back to order 0 when it reaches the latest :p 17:13:25 <planetmaker> yep. basically. 17:13:50 <planetmaker> No, the aim is simple: give all intercity trains the same orders. And they pick the route themselves based on the load percentage they get 17:14:41 <planetmaker> But I'll need n! * 5 order entries :-) 17:15:15 <TrueBrain> sick 17:15:17 <planetmaker> @calc 12! 17:15:17 <DorpsGek> planetmaker: Error: unexpected EOF while parsing (<string>, line 1) 17:15:20 <planetmaker> hm... 17:15:27 <planetmaker> yes, I know. 17:15:37 <planetmaker> But saves the hassle to look where trains are missing. 17:15:42 <frosch123> @calc factorial(12) 17:15:42 <DorpsGek> frosch123: Error: 'factorial' is not a defined function. 17:15:45 <planetmaker> Just add further trains and it will sort out :-) 17:15:52 <DaleStan> 12! = 479001600 17:15:56 <TrueBrain> @calc fac(12) 17:15:56 <DorpsGek> TrueBrain: Error: 'fac' is not a defined function. 17:16:01 <TrueBrain> weird 17:16:23 <planetmaker> hm... that's a lot... 17:16:31 <planetmaker> hm... wait, it's not factorial... 17:16:32 <_ln> @calc define f (x) { if (x <= 1) return (1); return (f(x-1) * x); } f(12) 17:16:32 <DorpsGek> _ln: Error: invalid syntax (<string>, line 1) 17:16:39 <TrueBrain> I think you need another approach ;) 17:16:55 <planetmaker> it's sum_i=1^n 5n 17:17:05 <frosch123> planetmaker: however VehicleOrderID is a byte 17:17:05 <TrueBrain> 1^n, sounds useful ;) 17:17:16 <planetmaker> :-P 17:17:30 <planetmaker> frosch123, ok, 254 and no more... 17:17:35 <planetmaker> I assumed so. :-) 17:18:12 <TrueBrain> maybe even 253 .. depends how many IDs are reserved ;) 17:18:15 <planetmaker> hm... I need 390 entries 17:24:33 <planetmaker> I guess I cut some options on low-traffic stations :-) 17:28:33 <CIA-2> OpenTTD: alberth * r16882 /trunk/src/rail_gui.cpp: -Codechange: Introduce a line_height variable in the station picker window. 17:45:39 <CIA-2> OpenTTD: translators * r16883 /trunk/src/lang/ (4 files): 17:45:39 <CIA-2> OpenTTD: -Update from WebTranslator v3.0: 17:45:39 <CIA-2> OpenTTD: simplified_chinese - 5 changes by Gavin 17:45:39 <CIA-2> OpenTTD: traditional_chinese - 4 changes by ww9980 17:45:39 <CIA-2> OpenTTD: russian - 12 changes by Lone_Wolf 17:45:40 <CIA-2> OpenTTD: slovak - 7 changes by James 17:46:35 *** fonsinchen [~alve@BAEcab6.bae.pppool.de] has joined #openttd 18:33:59 *** oskari89 [oskari89@88.193.124.243] has joined #openttd 18:38:40 *** Trenskow [~trenskow@x1-6-00-1e-52-6c-fd-ac.k344.webspeed.dk] has joined #openttd 18:48:18 *** paul_ [~paul@host86-140-69-225.range86-140.btcentralplus.com] has joined #openttd 18:49:21 *** orudge` [~orudge@189.87.115.33] has quit [Ping timeout: 480 seconds] 18:49:33 *** orudge` [~orudge@189.87.115.33] has joined #openttd 18:49:36 *** mode/#openttd [+o orudge`] by ChanServ 18:50:25 *** paul_ [~paul@host86-140-69-225.range86-140.btcentralplus.com] has quit [] 18:51:39 *** paul_ [~paul@94.76.226.86] has joined #openttd 18:52:13 *** DephNet[Paul] [~paul@94.76.226.86] has quit [Ping timeout: 480 seconds] 18:53:58 *** paul_ [~paul@94.76.226.86] has quit [] 18:55:05 *** DephNet[Paul] [~paul@94.76.226.86] has joined #openttd 18:56:19 *** orudge`` [~orudge@189.87.115.33] has joined #openttd 18:56:19 *** orudge` [~orudge@189.87.115.33] has quit [Read error: Connection reset by peer] 18:56:33 *** orudge`` is now known as orudge` 18:57:17 *** Progman [~progman@p57A1FB6E.dip.t-dialin.net] has joined #openttd 18:57:54 *** Progman [~progman@p57A1FB6E.dip.t-dialin.net] has quit [Remote host closed the connection] 19:00:49 *** Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has joined #openttd 19:01:07 *** Progman [~progman@p57A1FB6E.dip.t-dialin.net] has joined #openttd 19:06:26 *** kingj is now known as KingJ 19:06:52 *** Forked [~kjetil@presenterer.formye.info] has quit [Ping timeout: 480 seconds] 19:17:56 <CIA-2> OpenTTD: frosch * r16884 /trunk/src/ (depot_gui.cpp train.h train_cmd.cpp): -Codechange: Add Train::GetFirstEnginePart() and use it. 19:19:10 *** Trenskow [~trenskow@x1-6-00-1e-52-6c-fd-ac.k344.webspeed.dk] has quit [Quit: Trenskow] 19:20:55 <TrueBrain> STUPID NETBEANS! It refuses to allow tabs in the beginning of a line :s 19:21:35 <TrueBrain> oh .. with hitting enter REALLY hard it does .. 19:21:44 <TrueBrain> just it refuses to show it is a \t .. 19:24:19 <frosch123> you have to press enter for tabs ? 19:24:26 <TrueBrain> no, for the settings to store 19:24:36 <TrueBrain> 50% of the time or something, it doesn't store my changes 19:24:38 <TrueBrain> dunno why :s 19:26:17 *** helb [~helb@84.244.90.60] has quit [Ping timeout: 480 seconds] 19:29:00 *** Tekky_ [~chatzilla@DSL01.83.171.172.225.ip-pool.NEFkom.net] has joined #openttd 19:31:40 *** helb [~helb@84.244.90.46] has joined #openttd 19:33:13 <frosch123> and does a java ide satisfy the start-up-in-less-than-a-second criterion? 19:33:25 <TrueBrain> yup 19:33:30 <frosch123> :o 19:33:32 <TrueBrain> first time not, but next times is relative fast 19:33:41 <TrueBrain> just the tons of plugins you seem to require 19:33:48 <TrueBrain> which all need you to accept a license 19:33:52 <TrueBrain> that is a bit .. less useful 19:33:56 <frosch123> _p 19:34:52 *** Tekky [~chatzilla@DSL01.83.171.178.245.ip-pool.NEFkom.net] has quit [Ping timeout: 480 seconds] 19:34:57 *** Tekky_ is now known as Tekky 19:35:04 <TrueBrain> and it notices I have a mercurial checkout 19:35:06 <TrueBrain> which is kind of nice 19:35:50 <TrueBrain> debugger attaches correctly 19:44:16 <fonsinchen> I have a funny desync (with timetable separation and cargodist): http://paste.openttd.org/183758 19:44:41 <fonsinchen> If anyone has an idea what that might be, please tell me. 19:46:06 <TrueBrain> the client goes in a train handler routine 19:46:08 <TrueBrain> the server doesn't 19:46:13 <TrueBrain> good luck hunting that down :) 19:46:23 <TrueBrain> this tells you where exactly the desyncs happens 19:46:30 <TrueBrain> the reason for the desync can be burried DEEP 19:46:33 <TrueBrain> very deep ... 19:46:46 <TrueBrain> if you can reproduce it on the same position every time 19:46:50 <TrueBrain> you can figure out which train it is 19:46:53 <TrueBrain> you can figure out the specs of the train 19:47:03 <TrueBrain> and you can figure out what goes wrong :) 19:47:21 <yorick> ew... 19:47:40 <fonsinchen> Well, I run it through valgrind first, hoping that it's a memory management problem ... 19:47:54 <TrueBrain> most likely you 'forget' to sync a variable or what ever 19:48:28 <frosch123> hmm, how do I type a formfeed 19:48:35 <fonsinchen> I don't think there is any hidden state in either timetable separation or cargodist. But of course I may be wrong 19:48:54 <planetmaker> timetable separation actually sounds like states needed 19:49:03 <TrueBrain> nobody said the state has to be hidden :) 19:49:05 <Alberth> frosch123: ^L iirc 19:49:10 <fonsinchen> Have a look at the patch, it doesn't add any fields 19:49:14 <TrueBrain> we had times the problem was hiding in plain sight 19:49:29 <TrueBrain> I never talked about a new field 19:49:33 <TrueBrain> I talked about syncing 19:49:40 <TrueBrain> in other words: the server does A, the client does B 19:49:49 <planetmaker> fonsinchen, it might just be the use of the wrong random (interactive vs. non interactive) 19:49:55 <TrueBrain> because something 'forgot' to tell either one something else changed 19:50:08 <fonsinchen> neither cargodist nor timetable use any random values 19:50:12 <TrueBrain> planetmaker: doesn't look like it, but yeah: possible ;) 19:50:16 <fonsinchen> but what about the syncing 19:50:20 <fonsinchen> what do you mean? 19:50:22 <Alberth> frosch123: \f 19:50:44 <TrueBrain> fonsinchen: if (vehicle.state == VEH_STOPPED) Random(); else NoRandom() 19:50:53 <TrueBrain> if server thinks state is STOPPED, but client thinks it is RUNNING 19:50:56 <TrueBrain> you desync 19:51:16 <fonsinchen> now as vehicle.state is saved that shouldn't be possible 19:51:31 <fonsinchen> or do I have to add any manual syncing anywhere? 19:51:35 <TrueBrain> but if at some point the server changes it, and the client doesn't 19:51:36 <TrueBrain> for what ever reason 19:51:45 <fonsinchen> yes 19:51:50 <frosch123> Alberth: using echo -e worked :) 19:51:58 <fonsinchen> only possible with random, though 19:52:02 <fonsinchen> or threads 19:52:11 <TrueBrain> random just shows the problem 19:52:17 <TrueBrain> the true problem can be lines deep 19:52:26 <TrueBrain> even hours before it happening, in theory 19:52:45 <TrueBrain> a few desyncs we had in the past were deep .. really deep :p 19:53:04 <TrueBrain> finding out what is a bitch, a real bitch 19:53:14 <TrueBrain> and for all we know, those two patches just make it visible 19:53:24 <planetmaker> hm... there was some configure option for desync debugging afaik. 19:53:32 <TrueBrain> planetmaker: the result you can see in his pastebin :) 19:53:39 <planetmaker> oh, ok :-P 19:53:52 <TrueBrain> in this case it tells us that the client went into handling a train 19:53:58 <TrueBrain> where the server went into handling a town 19:54:18 <fonsinchen> the problem happens just 2 minutes after loading the savegame 19:54:20 <TrueBrain> giving me the strong impression something synced wrong :) 19:54:30 <TrueBrain> example: a train leaves a station in server sooner than in client 19:54:32 <planetmaker> :-D 19:54:39 <Aali> I remember debugging a desync where cargo packets were loaded slightly different on client/server 19:54:44 <Aali> that was "fun" 19:54:49 <TrueBrain> BE/LE problems 19:54:51 <TrueBrain> fun fun 19:54:56 <TrueBrain> initialization problems 19:55:00 <TrueBrain> I have seen too many desyncs :( 19:55:11 <TrueBrain> (hell, I wrote the initial versions of the desync tracers :p 19:55:18 <planetmaker> :-) 19:55:19 <fonsinchen> both client and server are running on the same machine - so endianness isn't the problem. 19:55:39 <fonsinchen> missing initialization might be 19:55:50 <TrueBrain> but as I said: find out which train it is 19:55:52 <TrueBrain> dump the content 19:55:54 <TrueBrain> figure out more 19:55:57 <TrueBrain> if you can reproduce it 19:55:58 <TrueBrain> you can trace it 19:56:00 <planetmaker> or initilisation which depends upon time 19:56:12 <planetmaker> can happen nicely with newgrf :-) 19:56:16 <planetmaker> or at least could 19:57:19 <fonsinchen> well, we'll see what I can find out. 19:57:24 <fonsinchen> Thanks for the advice 19:57:38 <planetmaker> May you have success :-) 19:57:46 <planetmaker> quick success 19:57:56 <TrueBrain> rule out as much as possible (grfs, 64bit, ...) 19:58:01 <TrueBrain> and you keep a small list of possibilities :) 19:58:05 <TrueBrain> but I would go for vehicle data at first :) 19:59:03 <Alberth> good night all 19:59:06 <TrueBrain> night Alberth 19:59:32 <TrueBrain> fonsinchen: other mostly useful tips: try reproducing on small maps (64x64) 19:59:37 <TrueBrain> and with as little as possible (1 or 2 trains) 19:59:44 <TrueBrain> avoids ... debug information :p 20:00:06 <Ammler> good night Alberth 20:00:16 <planetmaker> night Albert 20:00:30 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd [] 20:00:44 <Tekky> I do not quite understand why it is necessary for the server and client to run in sync. Would it not be sufficient if the actual game only runs on the server and the server then notifies the clients of all important events, such as a train leaving a station or a train selecting a specific route. Then, the approximations by the client should be sufficient; it would not matter if a client... 20:00:46 <Tekky> ...displays the position of a train wrongly by a fix pixels, as this position information would be corrected by the next update from the server. 20:01:00 <Tekky> This would have the advantage that you would also be allowed to use floating point numbers for train physics calculations, since desyncs due to different floating point implementations would no longer be a problem. 20:01:16 <TrueBrain> Tekky: http://www.tt-forums.net 20:01:29 <TrueBrain> use the searh 20:01:38 <TrueBrain> for your floating point 'suggestion': avoid floating point in any real application 20:01:46 <TrueBrain> floating points are SSLLOOOWWWWWW 20:01:50 <TrueBrain> (and mostly completely unneeded) 20:06:33 <_ln> but good for storing dates as they already contain a dot. 20:06:53 <_ln> (yes, i'm kidding.) 20:07:53 <TrueBrain> forgetting to reset an itimer can have nasty side-effects ... ghehe 20:11:34 <Tekky> TrueBrain: Floating point numbers are very common in all physics calculations and also in general 3D calculations, as far as I know. Besides, this was just one example of the benefits of not running server and client in sync. Are you saying that my proposal of not running server and client in sync has been suggested in the forums before? Or are you only talking about floating point calculations? 20:11:57 <TrueBrain> I made very clear I was refering to two entries 20:12:06 <TrueBrain> on one side the sync stuff, which has been talked over so many times I refuse to talk about in here 20:12:20 <TrueBrain> on the other side floats; although they are used for stuff, it is really bad to use it in a real application like OpenTTD 20:12:33 <TrueBrain> it has no use, no extra value, and all physic stuff can be rewritten to use ints 20:14:01 <frosch123> Tekky: btw. how big is a ottd savegame, and how often do you want to transfer it between server and client? 20:14:01 <Tekky> Hmmmm, when I search the OpenTTD Development Forum for the keyword "sync", I am unable to find any such discussion. 20:15:04 <Eddi|zuHause> happens more often in this channel, probably 20:15:37 <TrueBrain> it also happens in most 'desync' threads 20:15:43 <TrueBrain> but okay, Tekky, I am sorry, there is not a dedicated thread for it 20:15:57 <TrueBrain> so let me put it in these words: either read the code, how the network works and stuff, or don't make suggestions :) 20:16:20 <TrueBrain> and sorry if that sounds harsh, but you have no idea how many 'briliant' people came and gave that suggestion 20:16:24 <TrueBrain> like we never thought about it or what ever :p 20:17:01 <Tekky> frosch123: I guess it is sufficient if the server notifies the client of important events, for example whenever a train starts, stops, enters and leaves a station or makes a pathfinding decision. 20:17:12 <TrueBrain> you guessed wrong 20:18:06 <frosch123> Tekky: so what about building fields, changing industry production, building town roads and houses, building fences on clear tiles, building trees, ... 20:18:15 <TrueBrain> growing trees! 20:18:24 <TrueBrain> (which will be the most bandwidth :p) 20:19:12 <frosch123> TrueBrain: not true, changing animation frames of industries will take more 20:19:24 <TrueBrain> frosch123: but that doesn't need syncing, does it? :) 20:20:04 <frosch123> depends on the grf, for ecs you surely need to 20:20:05 <Tekky> frosch123: It is my understanding that already now all build command are handled by the server and the server then notifies the clients of the build. Is this assumption of mine wrong? 20:20:11 <TrueBrain> frosch123: fair enough ;) 20:20:39 <frosch123> Tekky: sure, but that only works as long as the clients are in sync 20:22:06 <TrueBrain> I once calculated the amount of bandwidth required to play a game on a 256x256 map (no trains, no grfs, no nothing) .. if I remember correctly, it required 500 kbit/sec or something :p A bit insane for such a simple game :) 20:22:15 <planetmaker> Tekky, the difference is: commands are player actions. What you want is EVERY change 20:22:22 <TrueBrain> (and that was including all kinds of weird optimizations and shortcuts :p) 20:30:37 *** Wolle [DrJekyll@p57B0D4D5.dip.t-dialin.net] has joined #openttd 20:31:14 <Tekky> planetmaker: Well, what changes most per tick are vehicle positions and speeds, at least if you disregard unimportant things such as tree growth/animation frames. It appears sufficient to me if all clients make approximations of these values. As soon as an important event occurs, such as a pathfinding decision made by a train, the server will update the clients' information about the... 20:31:15 <Tekky> ...position and speed of the train, so slight inaccuracies of position and speed of trains should not matter. I can't imagine that it would take too much bandwidth for the server to notify the clients about all such important events, unless your bandwidth is severely limited, when you are for example using a mobile phone. 20:31:48 <TrueBrain> I think Tekky will be making us a patch 20:31:50 <TrueBrain> best of luck 20:33:11 <TrueBrain> 'unimportant things such as tree growth' .. he clearly has no clue about the game :) Hihi :) 20:33:58 <Tekky> Hehe, yes, I am aware that the whole tree growth algorithm would have to be changed. :) 20:34:09 <TrueBrain> lets change the whole game 20:34:30 <Eddi|zuHause> Tekky: "animation frame" does not necessarily have anything to with animation... some newgrfs use that as some arbitrary memory 20:34:41 <yorick> lets make openttd WITH!!!!! better multiplayer 20:34:43 <TrueBrain> Eddi|zuHause: so lets change that! 20:35:12 <TrueBrain> I think we have to remove most of the GUI too, as that would only give wrong estimations ... 20:35:52 <TrueBrain> hehe: you remove a tile of what you think is a clear tile 20:35:58 <TrueBrain> you see 400,000 going away 20:35:59 <TrueBrain> WTF? 20:36:02 <TrueBrain> turns out it was a sea tile now 20:36:05 <Eddi|zuHause> :) 20:36:07 <TrueBrain> oopsie ... well .. unimportant 20:36:24 <TrueBrain> things you have to live with when you want servers to do the calculations 20:37:13 <TrueBrain> Tekky: short answer: OpenTTD changes so much in its gamestate EVERY SINGLE tick, it would be undoable (bandwidth wise) to sync that to all clients every tick 20:37:16 <OwenS> And transfering all that important data only when it's needed. Good luck. For our current game... Thats about 500kb/s 20:37:21 <OwenS> 500kb** 20:38:02 <TrueBrain> OpenTTD was not built with a server/client model in mind, where freeciv is, for example :) 20:38:11 <OwenS> And I'm being generous here and assuming 70% of the savegame size the clients already have. This is likely not the case 20:38:31 <Chruker> The server should be the only thing with the complete game state. Clients should just be glorified remote windows 20:38:41 <TrueBrain> RPC! 20:38:49 <TrueBrain> Chruker: well, in fact, I once explored this theory 20:38:50 <frosch123> indeed, likely it is better to play ottd via a x connection 20:38:51 <yorick> lets make openttd-vnc! 20:38:56 <TrueBrain> to send to a client only a VERY limited view of the map 20:39:00 <TrueBrain> to allow explosive big maps 20:39:04 <TrueBrain> (up to 1Mx1M) 20:39:21 <TrueBrain> it is doable, I can tell you .. 20:39:21 <Eddi|zuHause> OwenS: just send non-deterministically, then you can also use the upload bandwidth of the clients :p 20:39:23 <TrueBrain> just ... 20:39:25 <TrueBrain> it needs a full rewrite 20:39:29 <TrueBrain> but that is a minor detail, I guess 20:39:37 <Chruker> yes, minor :-) 20:39:38 <Chruker> ;-) 20:39:55 <OwenS> Eddi|zuHause: That doesn't help me where for some reason OpenTTD fails to get more than 20kb/ downlink to me for some reason... 20:40:02 <Eddi|zuHause> if you are at it, you can also make it multithreaded :p 20:40:05 <TrueBrain> well, 'full rewrite' is not true, you can keep the GUI :) 20:40:29 <Eddi|zuHause> oh, and 3D 20:40:43 <frosch123> or just join #transportempire 20:40:48 <TrueBrain> oh, and make sure it gives me 1M (real) euros every day 20:41:00 <OwenS> And rewrite it all in D beccause D is awesome 20:41:01 <Xaroth> 1m? 20:41:03 <Xaroth> every day? 20:41:22 <Xaroth> greedy bastard, i'd be satisfied with 1m a month :P 20:41:26 <Tekky> I am aware that this would require major changes to the internal structure of OpenTTD, so one should only do this if there is a good reason for doing so. However, when I see the amount of patches that don't make it into trunk because of problems with hunting down desycns, I do think it is worthwhile to ask the question whether the current multiplayer design of OpenTTD is meaningful or not. 20:42:11 <OwenS> Most similar types of game work the same way. They just don't have this issue because everyone runs the same version 20:42:54 <OwenS> Oh, and TrueBrain, I reject the assertion that floats are slow 20:42:54 <TrueBrain> Xaroth: okay, then you can get 1M every month :p 20:43:00 <Eddi|zuHause> Tekky: you really think that the desyncs are the problem? 20:43:23 <Eddi|zuHause> or are they rather a symptom of deeper problems? 20:43:31 *** Zorn [~zorn@e177238039.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] 20:43:43 <OwenS> Such as doing stuff in callbacks your not to do such stuff in 20:43:54 <TrueBrain> it is like you have a fever .. sure you can cure the fever by taking some pills .. but maybe .. just maybe .. it is something more, which you should have looked into 20:44:17 <TrueBrain> OwenS: run a loop where you do tons of divides 20:44:23 <TrueBrain> now do the one with floats, the other with ints 20:44:27 <TrueBrain> you tell me which is faster :p 20:44:44 <OwenS> TrueBrain: OK. In this loop, I'll be using SSE. Is this OK? ;-) 20:44:51 <TrueBrain> nope :) 20:45:04 <OwenS> PowerPC Altivec? 20:45:15 <TrueBrain> well, in fact I don't care what you use 20:45:24 <TrueBrain> as long as one uses the FPU, the other the CPU, it is fine by me :p 20:45:32 <Eddi|zuHause> for what platform is openttd (windows) usually compiled? i586? i386? 20:45:37 <TrueBrain> and I know, nowedays the differences are minimal 20:45:41 <TrueBrain> just avoiding float is always a good thing :) 20:45:55 <TrueBrain> Eddi|zuHause: i386, windows doesn't really define i[456]86 or 20:46:00 <TrueBrain> although documentation is vague on the subject 20:46:08 <OwenS> Heck, most computers have more floating point power than integer. It's just all hidden inside the GPU :p 20:46:22 <TrueBrain> OwenS: which assumes you have a GPU worth talking about ;) 20:46:29 <TrueBrain> the reason I say: FPU ;) 20:46:42 <Tekky> TrueBrain: Regarding your example about deleting a water tile: I do consider all changes to the terrain data as "important events", so that all terrain data must be kept in sync with client and server. However, things such as train positions and speed do not necessarily have to be kept in sync, in my opinion, as it does not matter if a client displays a train position wrongly by a few... 20:46:44 <Tekky> ...pixels. It would only be a problem if the train were displayed on the wrong path. Therefore, it should be sufficient if all clients are notified of important events such as pathfinding decisions, in my opinion. 20:46:47 <OwenS> TrueBrain: Even a crappy GMA beats most CPUs 20:47:10 <TrueBrain> so terrain is important 20:47:15 <TrueBrain> and a moment ago you said tree growth isn't? 20:47:17 <TrueBrain> now you make no sense 20:47:20 <fonsinchen> The problem with my desync is that the vehicle pool is broken on the client. It show first_unused=2091 while on the server it's 67. I still suspect a memory management problem ... 20:47:21 <TrueBrain> OwenS: true true 20:47:38 <TrueBrain> fonsinchen: I suspect bad patch 20:47:39 <Eddi|zuHause> Tekky: do you have an idea how many pathfinding decisions are done every tick? 20:47:48 <fonsinchen> of course one of the patches is bad 20:47:58 <fonsinchen> the tricky part is finding out if it's mine or the other 20:48:01 <TrueBrain> fonsinchen: how many vehicles are in the pool? 20:48:05 <fonsinchen> 67 20:48:13 <fonsinchen> I mean 67 is correct 20:48:17 <fonsinchen> 2091 is false 20:48:24 <frosch123> Eddi|zuHause: number of vehicles / 100 ? 20:48:48 <OwenS> Incidentally, random bug: When I throw OpenTTD from one display to another (maximized on both), it doesn't update it's size 20:48:49 <TrueBrain> fonsinchen: sorry, have been out too long of this to give you useful hints and tips 20:48:55 <TrueBrain> fonsinchen: just: make sure to use printf, and not gdb 20:49:00 <TrueBrain> gdb fucks up using optimizations 20:49:13 <TrueBrain> OwenS: http://bugs.openttd.org/ ;) 20:49:14 <fonsinchen> The code isn't optimized 20:49:20 <Tekky> Eddi|zuHause: Number of pathfinding decisions is equal to the number of trains reaching a track intersection, at least when using non-PBS signals. 20:49:20 <Eddi|zuHause> i don't know... but let's for the sake of argument use "10" [1000/100] 20:49:24 <fonsinchen> I mean no compiler optimization 20:49:26 <TrueBrain> fonsinchen: you sure? You used -O0? (even then, I wouldn't bet on it :p) 20:49:30 <fonsinchen> yes 20:49:35 <TrueBrain> believe me, you want to use printf :p 20:49:53 *** Xeryus|bnc is now known as XeryusTC 20:50:10 <Eddi|zuHause> then for each such decision, the vehicle-ID, the vehicle position (tile, trackbit), and cosen path must be transferred 20:50:14 <TrueBrain> fonsinchen: but okay, I wouldn't know what first_unused indicates, so I can't help you there :) Maybe someone else can :) 20:50:33 <TrueBrain> fonsinchen: but it is a hell of a road, with a lot of guesses and following hunches ... 20:50:44 <fonsinchen> it believes there are 2090 vehicles in the pool, so FOR_ALL_VEHICLES shows zombies 20:50:48 <Eddi|zuHause> let's say that these can be put into 64 bits 20:50:49 <TrueBrain> and in the end, you forgot to assign a value to a static variable or something stupid :p 20:51:15 <TrueBrain> fonsinchen: in the old days the first 2048 vehicles were 'special' vehicles, but ... don't ask me if that still is true :) 20:51:22 <TrueBrain> I wouldn't be able to tell you :) 20:51:25 <TrueBrain> my knowledge is OLD! 20:51:43 <yorick> 42! 20:51:53 <Tekky> Eddi|zuHause: The entire chosen path to the destination does not have to be transferred, only the direction chosen. 20:52:26 <yorick> and 42 happens to be 2x21 :-) 20:52:41 <TrueBrain> 7*8, you silly 20:53:19 <frosch123> 56? 20:53:24 <TrueBrain> no, 42!! 20:53:25 <TrueBrain> sigh :( 20:53:26 <Eddi|zuHause> but then you have 64bit * 10 decisions per tick * 33 ticks per second, that are about 20kbit/s for the pathfinder alone 20:54:03 <TrueBrain> 6 times 9? 20:54:13 <TrueBrain> (see if you can guess right this time :p) 20:54:51 *** DephNet[Paul] [~paul@94.76.226.86] has quit [Read error: Connection reset by peer] 20:54:54 <Eddi|zuHause> #define SIX 1+5 20:55:00 <Eddi|zuHause> #define NINE 8+1 20:55:05 *** DephNet[Paul] [~paul@94.76.226.86] has joined #openttd 20:55:06 * TrueBrain hugs Eddi|zuHause 20:55:39 <TrueBrain> "I refuse to answer that question on the grounds that I don't know the answer. " 20:56:13 <TrueBrain> "Anything that happens, happens. Anything that, in happening, causes something else to happen causes something else to happen. Anything that, in happening, causes itself to happen happens again. All of this, however, doesn't necessarily happen in chronological order. " 20:56:16 <TrueBrain> I love thatone :) 20:56:17 <Tekky> Eddi|zuHause: Ah, yes, that could indeed become a problem, especially since most of us have ADSL, where the upstream bandwidth is ten times less than the downstream bandwidth. 20:56:39 <KenjiE20> hehe 20:57:35 <Tekky> It never made sense to me why most DSL connection have ten times less upload capacity than download capacity. 20:58:00 <TrueBrain> because to download at full speed you need 10% of that speed as upload 20:58:11 <TrueBrain> simple TCP/IP stream calculation (of the old days) 20:58:22 <Eddi|zuHause> that was based on some manager's calculations that most internet users are "passive" 20:58:32 * yorick will get 50mb/s sync 20:58:54 <TrueBrain> has 100 mbit/s up+down 20:58:57 <Eddi|zuHause> that was before torrents were invented :p 20:58:59 <yorick> :-( 20:59:12 <Eddi|zuHause> or... napster... 20:59:19 <TrueBrain> Eddi|zuHause: it still is a truth you need about 1/10th of your download speed as upload to download at full speed :) 20:59:20 * yorick could get 100 mbit/s up+down, but it costs 60 euros a month extra :( 20:59:21 <frosch123> 'Did you know... You can disable these tips on startup if you uncheck the "Show tips at startup" box below' <- just brilliant as hint after first start 20:59:24 <TrueBrain> even 1/8th for torrents :p 20:59:26 * KenjiE20 has 700kbps down / 448 kbps up :P 20:59:45 <TrueBrain> I pay 12 euro 50 a month :p 20:59:56 <yorick> grrrr 20:59:58 <yorick> uni 21:00:01 <KenjiE20> hurrah for not being big enough for BT to give a rats 21:00:03 <TrueBrain> surfnet 21:00:05 <TrueBrain> yup 21:00:25 <Eddi|zuHause> frosch123: oh... damn... if only i had known that from the start... 21:02:16 <TrueBrain> I HATE OVERLAYS! (16bit dos stuff) 21:02:16 <Tekky> Eddi|zuHause: Yes, I think you have convinced me that what I propose would only work reliably with SDSL connections and would only work on ADSL with smaller games. 21:06:36 <frosch123> night 21:06:40 *** frosch123 [~frosch@frnk-590fd0be.pool.einsundeins.de] has quit [Remote host closed the connection] 21:06:40 <TrueBrain> night frosch123 21:06:42 <TrueBrain> darn 21:07:25 *** Nite_Owl [~Nite_Owl@c-76-109-50-97.hsd1.fl.comcast.net] has joined #openttd 21:07:39 *** Azrael- [~azraeluk@cpc4-papw2-0-0-cust778.cmbg.cable.ntl.com] has quit [Ping timeout: 480 seconds] 21:07:43 <Nite_Owl> Hello all 21:07:47 <TrueBrain> morning Nite_Owl 21:07:59 <Nite_Owl> Hello TrueBrain 21:08:23 <TrueBrain> am I not included in the all? :( 21:10:07 <Nite_Owl> Yes you are. I always do an 'all' and then respond individually to whomever responds to the 'all'. 21:10:16 <TrueBrain> ;) 21:12:20 <Nite_Owl> Can anyone give me an example of a reason to have a single waypoint span multiple tracks from a "this is useful on my network because' point of view? 21:12:49 <Akoz> yes 21:13:05 *** tdev [~udev@p508EB131.dip.t-dialin.net] has joined #openttd 21:13:15 <Akoz> you have trains coming from nearby and from far away going into the same station. at the exit you want to send those from far away into depots 21:13:16 <TrueBrain> welcome tdev 21:13:25 <Akoz> you have enough trains that you have several depots, each wich one single line 21:13:40 <Akoz> having a waypoint span over those lines and then sending the trains to that waypoint would be imba 21:13:48 <tdev> hi TrueBrain :) 21:14:39 <KenjiE20> also, multitrack avoidance loops 21:15:29 <Eddi|zuHause> separating platforms by direction 21:15:37 <Eddi|zuHause> use platforms 1-3 for direction A 21:15:46 <Eddi|zuHause> use platforms 4-5 for direction B 21:16:07 <Nite_Owl> Akoz: could you not do the same thing by giving the trains specific depot orders 21:16:11 <Eddi|zuHause> use platforms 6-8 for trains that turn around 21:17:10 <Eddi|zuHause> or separating trains by cargo type 21:17:47 <Akoz> nite_owl: yes, but then if two trains have the same depot order they will queue on one depot instead of going to the free one nearby 21:18:11 <Akoz> and its much more tedious 21:18:24 <Akoz> also with waypoint its easier to expand 21:18:28 <Akoz> add more tracks with depots 21:18:42 <Akoz> without having to re-give orders to all those 200 trains u have going into the same station 21:18:43 <KenjiE20> and would get annoying with trains crossing the junction and/or shared orders 21:18:53 <Akoz> right 21:19:01 <TrueBrain> Akoz: isn't multispan depots easier? 21:19:11 <Akoz> is that possible? 21:19:13 <Nite_Owl> That is valid as is Eddi's example 21:19:21 <TrueBrain> that wasn't the question ;) 21:19:22 *** ecke [~ecke@213.195.202.11] has quit [Quit: ecke] 21:19:38 <Akoz> I'd go with waypoints instead if I could choose 21:19:48 <Eddi|zuHause> TrueBrain: i was under the impression that internally, waypoints are much closer to depots than to stations 21:20:24 <TrueBrain> Eddi|zuHause: yeah .. something like that I guess 21:20:46 <TrueBrain> I never used WPs, that is why I ask Akoz :) 21:20:52 <Akoz> for instance having 8-tracks around the map trains do sometimes get lost simply because its too far for the pathfinder to find a way, or they choose a very unoptimal route.. setting waypoints that span several tiles would be the solution.. basically whatever you can use a 1-tile waypoint for you need a multi-tile waypoint for if you want to do it on a multi-track network 21:20:52 <Eddi|zuHause> so making waypoints multi-tile would be roughly the same effort as making depots multi-tile 21:21:15 <TrueBrain> Akoz: PF problems are outdated with YAPF :) 21:21:25 <TrueBrain> that would have holded with older PFs, but not with YAPF :) 21:21:34 <Nite_Owl> KenjiE20: what are multitrack avoidance loops? is there an example on the coop site? 21:22:35 <KenjiE20> not a clue, but basically if you want a set of train to go a certain way to avoid something, and there's more trains than 1 track can handle.... 21:22:47 <KenjiE20> voila 21:23:16 <Akoz> how about simply balancing loads on tracks? 21:23:17 <Nite_Owl> I will buy that 21:23:32 <Akoz> you have 3 tracks going from a to b and you have 3 more going from a through c to b 21:23:44 <TrueBrain> I wish you all a very good night 21:23:47 <Nite_Owl> Thank you all - my question is answered 21:23:49 <Akoz> all trains choose the direct route and it gets clogged.. you want to reroute nonessential trains to the longer route 21:23:57 <Nite_Owl> later TrueBrain 21:24:04 <Akoz> gn 21:24:18 <KenjiE20> nite TrueBrain 21:24:29 <Tekky> Nite_Owl: Yes, on my current network, I had many trains with a go to depot order before they pick up more cargo. However, I found out that this single depot is not sufficient to serve all trains, so I built a second depot and put a waypoint in front of both depots. I then gave my trains the order to go to the waypoint and then "go to nearest depot". This worked very well, however, now I have... 21:24:31 <Tekky> ...the problem that traffic jams occur because all my trains are limited to one single lane of track, because the waypoint can only be on one line of track. I am now forced to make two lanes of track, each having its own waypoint, and to divide my trains with shared orders into two different groups, so that half of the trains use one waypoint and half use the other waypoint. This would not... 21:24:33 <Tekky> ...be necessary if waypoints could span multiple tracks. 21:24:49 <KenjiE20> wall of text 21:25:45 <Akoz> What tekky said.. :) 21:25:51 <KenjiE20> yes 21:26:34 <Nite_Owl> well you can use single station tiles to span multiple tracks and then use the 'via' order 21:27:20 <Akoz> then you can do that for waypoints too.. you might as well remove the waypoints :) 21:27:21 <Tekky> Nite_Owl: Yes, but then I have an unserviced station which gives me a rating penalty from the authorities. 21:27:37 <KenjiE20> and you'd have to remove track 21:27:46 <KenjiE20> screwing with heavy flowing lines 21:28:07 *** Dred_furst` [~Dred@user-544348a3.lns6-c7.dsl.pol.co.uk] has joined #openttd 21:28:50 <Akoz> and ofc it can only be as big as the station size 21:28:54 <Nite_Owl> understood - I do not worry about ratings that much personally but I do see your point 21:28:58 <Akoz> although I guess that might be the same problem with waypoints 21:29:38 <Akoz> for instance if you have a 10 x 10 station, and you want to split each line into 2 depots for maximum flow.. thats 20 lines :p 21:29:53 *** yorick [~Yorick@s55924da0.adsl.wanadoo.nl] has quit [Quit: Poef!] 21:30:04 *** TheCondor [~thecondor@82-169-216-227.ip.telfort.nl] has quit [Quit: ( www.nnscript.de :: NoNameScript 4.1 :: www.regroup-esports.com )] 21:30:36 <KenjiE20> not forgetting with stations, if one train has a bad order.... 21:32:21 <Akoz> right. stops :p 21:32:56 <KenjiE20> and potentially starts a rivalling pax pickup 21:33:02 <KenjiE20> or whatever 21:34:21 <Akoz> right 21:35:34 *** Dred_furst [~Dred@user-544348a3.lns6-c7.dsl.pol.co.uk] has quit [Ping timeout: 480 seconds] 21:35:53 *** Dred_furst` [~Dred@user-544348a3.lns6-c7.dsl.pol.co.uk] has quit [Read error: Connection reset by peer] 21:36:06 <Nite_Owl> well at least now I have some idea of how a single waypoint spanning multiple tracks might be useful. it just never popped into my head before given the way I build networks. 21:36:14 *** Dred_furst` [~Dred@user-544348a3.lns6-c7.dsl.pol.co.uk] has joined #openttd 21:39:42 <Nite_Owl> of course all of this stems from an answer I gave to a post on the forum and the responses to my answer 21:40:25 *** Dred_furst` [~Dred@user-544348a3.lns6-c7.dsl.pol.co.uk] has quit [Read error: Connection reset by peer] 21:44:16 *** fonsinchen [~alve@BAEcab6.bae.pppool.de] has quit [Remote host closed the connection] 21:50:10 *** Biolunar [mahdi@blfd-4db01d42.pool.einsundeins.de] has quit [Quit: gn8] 21:55:37 <Akoz> are there any known bugs with multiplayer passwords in 0.7.1? 21:58:51 <SmatZ> no 22:01:09 *** orudge` [~orudge@189.87.115.33] has quit [Ping timeout: 480 seconds] 22:02:34 <Akoz> ty 22:09:53 *** KritiK [~Maxim@78-106-215-137.broadband.corbina.ru] has quit [Quit: Leaving] 22:14:23 *** orudge` [~orudge@189.87.115.33] has joined #openttd 22:14:26 *** mode/#openttd [+o orudge`] by ChanServ 22:18:47 *** Progman [~progman@p57A1FB6E.dip.t-dialin.net] has quit [Remote host closed the connection] 22:18:52 *** TheMask96 [martijn@greed.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 22:19:52 <Akoz> what I really would want is to be able to flag depots.. to allow trains to go to only specific depots when they need servicing 22:20:02 <Akoz> then you wouldnt need depots at every junction to avoid trains getting lost 22:23:29 <Nite_Owl> give them 'go to depot' or 'service at depot' orders 22:24:05 <Nite_Owl> they will only go to those depots 22:25:49 *** TheMask96 [martijn@greed.vhost.ne2000.nl] has joined #openttd 22:28:37 <Akoz> I mean I would like a set of depots they can go to 22:28:57 <Akoz> without having to micro each train by giving specific depot orders 22:29:44 <Akoz> as it is now if a train has a really long path on a "main line" when the time comes it decides it needs service it'll take off at the first junction where there is a depot nearby.. if that is a typical loading station with depot behind a station as only line out the train is stuck 22:29:55 <Akoz> to combat that one has to build depots at every intersection at the main track 22:33:50 <Akoz> do you know what I mean? 22:34:22 <Nite_Owl> yes 22:36:05 <Nite_Owl> build depots before (but close by) your loading stations and give all of the trains that load at that station a 'service at depot' order for that specific depot 22:37:34 *** KingJ is now known as kingj 22:40:44 *** oskari89 [oskari89@88.193.124.243] has quit [Quit: Utm Aœ - Aja 35] 22:40:51 <Akoz> then they wont go to any other depot even if they get to 0 reliability? 22:41:34 <Nite_Owl> they should not but I would not swear to that 22:42:23 <Akoz> :p 22:42:42 <Akoz> but then thats not really helping either.. I could get the same effect by turning the servicing time up to "infinite" for all vehicles 22:42:59 <Akoz> I always have a depot before or after a loading station (or both) 22:43:26 <Akoz> but when having cross-map tracks trains might need 1-2 depot stops per way 22:43:57 <Akoz> then I have to predict myself when the train will need depot stops and make the appropriate orders 22:44:21 <Akoz> and if traffic clogs up a bit trains will end up at really low reliabilities potentially causing jams 22:44:32 <Nite_Owl> you can put in multiple 'service at depot' orders 22:44:54 <Akoz> is there a difference between service at depot, and just go to depot? 22:45:10 <Akoz> I never got that.. reliability is up to max in either case 22:45:23 <Nite_Owl> service at depot = stop if needed go to depot = always stop 22:45:39 <Akoz> and what decides if it is needed? 22:45:59 <Nite_Owl> depends on your servicing settings 22:46:18 <Akoz> with default? 22:46:38 <Nite_Owl> 180 days ? 22:47:12 <Akoz> for example 22:47:34 *** stuffcorpse [~rick@121.98.136.241] has quit [Remote host closed the connection] 22:47:50 *** stuffcorpse [~rick@121.98.136.241] has joined #openttd 22:48:53 <Nite_Owl> so a train will travel for 180 days before it needs to stop at a depot - or close to 180 days 22:49:51 <Nite_Owl> if you have a very long route you would plan out your depots accordingly 22:50:49 <Nite_Owl> I play with breakdowns off but servicing on and my servicing interval set to 365 days 22:50:58 <Akoz> ^^ 22:51:08 <Akoz> well if you play with breakdowns off it doesnt really matter 22:51:13 <Nite_Owl> so once a year my trains visit a depot 22:51:15 <Xaroth> I disable servicing when breakdowns are off :P 22:51:46 <Akoz> my point is 22:51:51 <Akoz> if you have a track that takes 500 days to complete 22:51:56 <Akoz> you probably need more depots 22:52:06 <Nite_Owl> I still like them to visit the depots for sake of the R word 22:52:18 <Akoz> if you track the train the first time and send it to depots so that it'll never get below say.. 70% thats fine for that train 22:52:38 <Akoz> if then later traffic causes the train to slow down it might get to 50% or less before it reaches that designated half way depot 22:52:52 <Akoz> then it'll take off and go to another random depot that will cause it to get lost 22:53:14 <Akoz> or if you have "infinite" time to depot it will continue until its 0% trying to get to the designated depot 22:53:38 <Akoz> further more these designated depots are a nightmare if you have to give ALL your trains extra orders to go to those depots 22:53:43 <Nite_Owl> not if you use depot orders - it will never hunt out a random depot 22:53:56 <Akoz> ok 22:54:12 <Akoz> so when travel time changes you need to re-do the orders for the trains 22:55:20 <Nite_Owl> Why? If it works for slower trains then it will work for faster ones too. 22:55:29 *** Chruker [~no@0x5da34ce4.vjnqu1.dynamic.dsl.tele.dk] has quit [] 22:55:35 <Akoz> if it changes positivly yes 22:55:48 *** Coco-Banana-Man [~Stephan.D@p5B2DE113.dip.t-dialin.net] has quit [Quit: Raubgut ist vom Umtausch ausgeschlossen!] 22:55:49 <Akoz> but if more traffic causes it to take longer time to travel you have a problem 22:56:07 <Akoz> and if you for any reason (construction?) get a train jam that causes trains to get to zero reliability you also get a huge problem 22:56:50 <Nite_Owl> then you may have to build in additional yards for the train(s) to stop in 22:56:56 <Akoz> right 22:57:06 <Akoz> but the biggest hinder for your approach is to set up the trains in the first place 22:57:16 <Akoz> having to add say 2 half way depots per way for each train 22:57:25 <Akoz> changing amount of orders from 2 to 6 for each train you make 22:57:30 <Akoz> thats a lot of extra work 22:57:45 <Akoz> easaier and safer to add depots at all exits 22:58:15 <Nite_Owl> not if you are sharing orders and have a good idea of when your trains will need service 22:58:24 <Akoz> Im always sharing orders 22:58:44 <Nite_Owl> then you only have to change the orders for one train 22:58:55 <Akoz> uhm. no 22:59:05 <Akoz> for each loading station you have a different set of orders 22:59:14 *** Azrael- [~azraeluk@cpc4-papw2-0-0-cust778.cmbg.cable.ntl.com] has joined #openttd 22:59:17 <Akoz> with typically 200 trains you probably have at least 50 loading stations 22:59:22 <Nite_Owl> yes - that is correct 22:59:23 <Akoz> and 50 sets of orders 22:59:48 <Nite_Owl> do you group your trains 22:59:54 <Akoz> not usually 23:00:05 <Akoz> never found a purpose for it 23:00:15 <Nite_Owl> it becomes much easier to do if you group them 23:00:35 <Akoz> how so 23:00:50 <Belugas> they do smoke togueter 23:00:55 <Belugas> nice and fun to see 23:01:00 <Nite_Owl> each group has only trains in it that share orders 23:01:16 <Akoz> as in identical orders? 23:01:20 <Nite_Owl> yes 23:01:30 *** Dred_furst [~Dred@user-544348a3.lns6-c7.dsl.pol.co.uk] has joined #openttd 23:01:31 <Akoz> uhm. then what is the point of grouping? when you change 1 order you change all 23:01:35 <Akoz> O_o 23:02:45 <Nite_Owl> Yes but it is easier to pick out the trains to change the orders for if they are in a group - you are picking one train out of each group 23:03:08 <Belugas> group them for any propose you want. it is a way to organize your fleet 23:03:36 <Belugas> i usually group my trains by usage, i.e cargo 23:03:40 <Belugas> or lines 23:03:41 <Akoz> I never got the point.. I mean if I want to change an order for the "fleet" from one specific station I just click the station, click the train icon at the bottom and pick a train to change the order 23:03:43 <Belugas> depends 23:04:02 <Akoz> acctually I usually just click the train already in the station 23:04:06 <Akoz> if theres an order change 23:04:15 <Akoz> theres always one train loading 23:05:14 <Nite_Owl> yes but then you have to go around to each station 23:05:30 <Nite_Owl> instead of to one open window 23:05:44 <Akoz> when do you want to change the order of all trains? 23:06:04 <Nite_Owl> all trains in a group? 23:06:16 <Akoz> the only case I see is when I have to change the final destination for instance if I want to change from one factory to another 23:06:32 <Nite_Owl> that is a good example 23:06:42 *** Tekky_ [~chatzilla@DSL01.83.171.191.44.ip-pool.NEFkom.net] has joined #openttd 23:06:46 <Akoz> and in that case I simply click the station the trains are going to and change the order to the other one. by having the "trains to this station" list they remove as soon as they are reassigned, so I can always click the top train 23:06:48 <Nite_Owl> also if you need to add a depot 23:14:57 *** Netsplit kinetic.oftc.net <-> charon.oftc.net quits: Sacro, @orudge`, Default__, @DorpsGek, Fuco, +Patrick`, Andel, N35, guru3, SirSquidness, (+70 more, use /NETSPLIT to show all of them) 23:16:09 *** Netsplit over, joins: Default__, Born_Acorn, Ammler, Sacro, SpComb, eQualizer, Xaroth, Aali, Andel, welshdragon (+58 more) 23:16:19 *** Netsplit over, joins: TheMask96, Wolle, helb, LadyHawk, Akoz, dfox, Exl, Zr40_, Westie, edeca 23:16:24 <Akoz> and.. we're back 23:16:33 <Akoz> wehee 23:16:36 <welshdragon> :P 23:17:13 *** Nite_Owl [~Nite_Owl@c-76-109-50-97.hsd1.fl.comcast.net] has quit [Quit: Read You Soon] 23:25:31 *** Aali_ [~aali@84-217-30-29.tn.glocalnet.net] has joined #openttd 23:26:30 *** mode/#openttd [+v orudge`] by ChanServ 23:26:30 *** ChanServ changed the topic of #openttd to: 0.7.1, 0.7.2-RC1 | Website: *.openttd.org (BaNaNaS: bananas, Translator: translator, Gameservers: servers, Nightly-builds: nightly, WIKI: wiki, Dev-docs: docs, Patches & Bug-reports: bugs, Revision log: vcs, Release info: finger) | #openttd.notice for SVN notices | UTF-8 please | No Unauthorised Bots | English only :D 23:27:17 *** Aali [~aali@84-217-25-171.tn.glocalnet.net] has quit [Ping timeout: 480 seconds] 23:29:58 *** mode/#openttd [+v DorpsGek] by ChanServ 23:31:30 *** Exl [~myself@cp1224652-a.roemd1.lb.home.nl] has quit [Quit: Bitches.] 23:33:03 *** Eddi|zuHause [~johekr@p54B74995.dip.t-dialin.net] has quit [] 23:33:18 *** Eddi|zuHause [~johekr@p54B77D53.dip.t-dialin.net] has joined #openttd 23:33:39 *** Tekky [~chatzilla@DSL01.83.171.163.103.ip-pool.NEFkom.net] has joined #openttd 23:39:52 *** Tekky_ [~chatzilla@DSL01.83.171.191.44.ip-pool.NEFkom.net] has quit [Ping timeout: 480 seconds] 23:44:17 *** Dred_furst [~Dred@user-544348a3.lns6-c7.dsl.pol.co.uk] has quit [Quit: Leaving] 23:44:48 *** tdev [~udev@p508EB131.dip.t-dialin.net] has quit [Quit: free open source vehicle simulator: http://rigsofrods.com]