Log for #openttd on 19th July 2009:
Times are UTC Toggle Colours
00:01:12  *** Azrael- [] has quit [Read error: Connection reset by peer]
00:03:41  *** Svish [~Svish@] has quit [Quit: Quit]
00:06:27  *** Svish [~Svish@] has joined #openttd
00:06:31  *** Svish [~Svish@] has quit []
00:07:54  *** Svish [~Svish@] has joined #openttd
00:10:03  *** orudge` [~orudge@] has quit [Ping timeout: 480 seconds]
00:20:08  *** Antigon [] has joined #openttd
00:21:34  *** orudge` [~orudge@] has joined #openttd
00:21:35  *** mode/#openttd [+o orudge`] by ChanServ
00:22:01  *** Antigon [] has quit []
00:27:27  *** Polygon [] has quit [Ping timeout: 480 seconds]
00:31:09  *** Illegal_Alien [~Illegal_A@] has quit [Read error: Connection reset by peer]
00:36:25  *** Svish [~Svish@] 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 [] has joined #openttd
00:44:44  *** KenjiE20 [~KenjiE20@] has quit [Quit: WeeChat 0.3.0-rc2]
00:45:01  *** Chruker [] 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@] 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 [] has quit [Quit: Raubgut ist vom Umtausch ausgeschlossen!]
00:56:03  *** Lakie` [~Lakie@] has joined #openttd
01:03:28  *** Lakie [~Lakie@] has quit [Ping timeout: 480 seconds]
01:15:12  *** orudge` [~orudge@] has joined #openttd
01:15:15  *** mode/#openttd [+o orudge`] by ChanServ
01:17:44  *** oskari89 [] has quit [Quit: Utm Aœ - Aja 35]
01:17:55  *** Chrill [~chrischri@] has quit []
01:32:31  *** Pygma [~quassel@] has joined #openttd
01:44:29  <Pygma> Hey
02:11:27  *** KenjiE20|LT [] has quit [Quit: Leaving]
02:15:19  *** orudge` [~orudge@] 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 [] has quit [Ping timeout: 480 seconds]
03:09:02  *** TinoDidriksen [] has quit [Ping timeout: 480 seconds]
03:09:53  *** Tekky [] has quit [Ping timeout: 480 seconds]
03:12:39  *** TinoDidriksen [] has joined #openttd
03:25:14  *** Lakie` [~Lakie@] has quit [Quit: Sleep.]
03:38:52  *** TinoDidriksen [] has quit [Ping timeout: 480 seconds]
03:42:57  *** TinoDidriksen [] has joined #openttd
03:48:21  *** `Fuco`` [] has quit [Ping timeout: 480 seconds]
03:56:52  *** Pygma [~quassel@] has quit [Remote host closed the connection]
04:39:20  *** reldred [~reldred@] has joined #openttd
04:56:33  *** ecke [~ecke@] has joined #openttd
05:51:21  *** roboboy [] has quit [Quit: ajax IRC Client]
06:25:06  *** roboboy [] has joined #openttd
06:29:46  *** ecke [~ecke@] has quit [Quit: ecke]
06:36:14  *** Netsplit <-> 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 [] has joined #openttd
06:59:21  *** FR^2 [] has joined #openttd
07:13:51  *** Tekky [] has joined #openttd
07:44:16  *** maristo [] has joined #openttd
07:48:55  *** Azrael- [] has joined #openttd
07:50:33  *** FR^2 [] has quit [Quit: Der Worte sind genug gewechselt, lasst mich auch endlich Taten sehn!]
07:54:38  *** Svish [~Svish@] has joined #openttd
07:58:30  *** Svish [~Svish@] has quit [Quit: Leaving]
07:59:05  *** Progman [] has joined #openttd
08:01:08  *** ecke [~ecke@] has joined #openttd
08:05:30  *** |Jeroen| [] has joined #openttd
08:10:17  *** Alberth [] has joined #openttd
08:12:55  *** FR^2 [] has joined #openttd
08:19:25  *** ecke [~ecke@] has quit [Quit: ecke]
08:55:02  *** frosch123 [] has joined #openttd
09:16:05  *** Coco-Banana-Man [] has joined #openttd
09:25:33  *** tokai [] has quit [Ping timeout: 480 seconds]
09:27:44  *** tokai [] has joined #openttd
09:27:47  *** mode/#openttd [+v tokai] by ChanServ
09:36:21  *** yorick [] has joined #openttd
09:39:39  *** fonsinchen [] has joined #openttd
09:40:42  *** ecke [~ecke@] has joined #openttd
09:43:38  *** George3 [~George@] has joined #openttd
09:49:37  *** George [~George@] has quit [Ping timeout: 480 seconds]
10:05:55  *** Mucht [] has quit [Remote host closed the connection]
10:10:54  *** Exl [] has joined #openttd
10:13:58  *** Tekky_ [] has joined #openttd
10:13:58  *** Tekky [] has quit [Read error: Connection reset by peer]
10:14:00  *** Tekky_ is now known as Tekky
10:21:36  *** Progman [] has quit [Remote host closed the connection]
10:26:16  *** dfox [] has quit [Ping timeout: 480 seconds]
10:51:29  *** KenjiE20 [~KenjiE20@] has joined #openttd
10:53:05  *** thingwath [~thingwath@] has quit [Quit: It's all over.]
11:01:19  *** Polygon [] has joined #openttd
11:04:15  *** |Jeroen| [] has quit [Quit: oO]
11:06:05  *** fjb [] has joined #openttd
11:06:11  <fjb> Hello
11:11:12  *** DJ-Burtybob [burtybob@] has joined #openttd
11:17:13  *** Mucht [] has joined #openttd
11:25:41  *** Wolfensteijn [] has quit [Quit: Changing server]
11:26:05  *** wolfy [] has joined #openttd
11:27:10  *** Chruker [] has joined #openttd
11:28:39  *** jolteon [] 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 [] 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 [] 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 [] has left #openttd []
11:35:54  *** Mucht [] has quit [Remote host closed the connection]
11:35:55  *** Polygon [] 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 [] 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 [] 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 [] 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 [] has quit [Read error: Connection reset by peer]
12:27:44  <yorick> then you have a too big game
12:27:45  *** MizardX [] 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>
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 [] 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 [] 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 [] has joined #openttd
12:48:30  *** fjb [] 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 [] has joined #openttd
13:00:31  *** OwenS [] 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_ [] 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 [] 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 [] has joined #openttd
13:16:38  <frosch123> yeah, only stuff starting with # or ! is worse
13:16:50  *** reldred [~reldred@] 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 [] has left #openttd []
13:20:00  *** FR^2 [] 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 [] 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 [] 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>
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@] 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>
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@] has joined #openttd
14:05:25  *** Zorn [] 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> <- 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@] 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_ [] 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 [] 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 [] 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_ [] 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] [] 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@] has joined #openttd
14:31:52  *** mode/#openttd [+o orudge`] by ChanServ
14:31:52  *** sdafsdf [] has joined #openttd
14:31:52  *** LadyHawk [] has quit [Read error: Connection reset by peer]
14:32:02  *** sdafsdf is now known as LadyHawk
14:32:10  *** [alt]buster [] has joined #openttd
14:32:57  *** Tekky [] has quit [Ping timeout: 480 seconds]
14:33:02  *** maristo [] 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 [] 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@] 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@] 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@] 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 [] 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 [] 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 [] has joined #openttd
15:22:58  *** TheMask96 [] 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] [] 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] [] 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] [] 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] [] 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] [] 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>
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>,_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 [] has quit [Read error: Connection reset by peer]
16:01:58  *** OwenS [] 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@] 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_ [] has joined #openttd
16:14:13  *** Tekky [] has quit [Read error: Connection reset by peer]
16:14:23  *** Tekky_ is now known as Tekky
16:19:07  *** DephNet[Paul] [] has quit [Ping timeout: 480 seconds]
16:19:49  *** OwenSX [] 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@] has quit [Quit: Leaving]
16:21:27  *** DephNet[Paul] [~paul@] has joined #openttd
16:22:17  *** Guest1588 [] has quit [Ping timeout: 480 seconds]
16:28:46  *** orudge` [~orudge@] has quit [Ping timeout: 480 seconds]
16:28:56  *** orudge` [~orudge@] has joined #openttd
16:28:59  *** mode/#openttd [+o orudge`] by ChanServ
16:38:17  *** Dragoon_Jett [] has joined #openttd
16:39:02  *** TheCondor [] 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>
16:39:49  <TrueBrain>
16:39:54  <TrueBrain>
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 [] 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 [] has joined #openttd
16:58:24  *** Progman [] 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 [] has joined #openttd
17:09:42  *** TheStarLion [] 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 [] has joined #openttd
18:33:59  *** oskari89 [oskari89@] has joined #openttd
18:38:40  *** Trenskow [] has joined #openttd
18:48:18  *** paul_ [] has joined #openttd
18:49:21  *** orudge` [~orudge@] has quit [Ping timeout: 480 seconds]
18:49:33  *** orudge` [~orudge@] has joined #openttd
18:49:36  *** mode/#openttd [+o orudge`] by ChanServ
18:50:25  *** paul_ [] has quit []
18:51:39  *** paul_ [~paul@] has joined #openttd
18:52:13  *** DephNet[Paul] [~paul@] has quit [Ping timeout: 480 seconds]
18:53:58  *** paul_ [~paul@] has quit []
18:55:05  *** DephNet[Paul] [~paul@] has joined #openttd
18:56:19  *** orudge`` [~orudge@] has joined #openttd
18:56:19  *** orudge` [~orudge@] has quit [Read error: Connection reset by peer]
18:56:33  *** orudge`` is now known as orudge`
18:57:17  *** Progman [] has joined #openttd
18:57:54  *** Progman [] has quit [Remote host closed the connection]
19:00:49  *** Mucht [] has joined #openttd
19:01:07  *** Progman [] has joined #openttd
19:06:26  *** kingj is now known as KingJ
19:06:52  *** Forked [] 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 [] 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@] has quit [Ping timeout: 480 seconds]
19:29:00  *** Tekky_ [] has joined #openttd
19:31:40  *** helb [~helb@] 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 [] 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):
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 [] 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:
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 [] 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 [] 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: ;)
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@] 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@] 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 [] has quit [Remote host closed the connection]
21:06:40  <TrueBrain> night frosch123
21:06:42  <TrueBrain> darn
21:07:25  *** Nite_Owl [] has joined #openttd
21:07:39  *** Azrael- [] 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 [] 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@] 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> 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` [] 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 [] has quit [Quit: Poef!]
21:30:04  *** TheCondor [] has quit [Quit: ( :: NoNameScript 4.1 :: )]
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 [] has quit [Ping timeout: 480 seconds]
21:35:53  *** Dred_furst` [] 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` [] 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` [] has quit [Read error: Connection reset by peer]
21:44:16  *** fonsinchen [] has quit [Remote host closed the connection]
21:50:10  *** Biolunar [] 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@] has quit [Ping timeout: 480 seconds]
22:02:34  <Akoz> ty
22:09:53  *** KritiK [] has quit [Quit: Leaving]
22:14:23  *** orudge` [~orudge@] has joined #openttd
22:14:26  *** mode/#openttd [+o orudge`] by ChanServ
22:18:47  *** Progman [] has quit [Remote host closed the connection]
22:18:52  *** TheMask96 [] 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 [] 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@] 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@] has quit [Remote host closed the connection]
22:47:50  *** stuffcorpse [~rick@] 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 [] has quit []
22:55:35  <Akoz> if it changes positivly yes
22:55:48  *** Coco-Banana-Man [] 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- [] 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 [] 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_ [] 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 <-> 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 [] has quit [Quit: Read You Soon]
23:25:31  *** Aali_ [] 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: * (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 [] has quit [Ping timeout: 480 seconds]
23:29:58  *** mode/#openttd [+v DorpsGek] by ChanServ
23:31:30  *** Exl [] has quit [Quit: Bitches.]
23:33:03  *** Eddi|zuHause [] has quit []
23:33:18  *** Eddi|zuHause [] has joined #openttd
23:33:39  *** Tekky [] has joined #openttd
23:39:52  *** Tekky_ [] has quit [Ping timeout: 480 seconds]
23:44:17  *** Dred_furst [] has quit [Quit: Leaving]
23:44:48  *** tdev [] has quit [Quit: free open source vehicle simulator:]

Powered by YARRSTE version: svn-trunk