Back to Home / #openttd / 2009 / 07 / Prev Day | Next Day
#openttd IRC Logs for 2009-07-19

---Logopened Sun Jul 19 00:00:43 2009
00:39-!-reldred [~reldred@] has joined #openttd
00:56-!-ecke [~ecke@] has joined #openttd
01:51-!-roboboy [] has quit [Quit: ajax IRC Client]
02:25-!-roboboy [] has joined #openttd
02:29-!-ecke [~ecke@] has quit [Quit: ecke]
02:36-!-Netsplit <-> quits: @Belugas, CIA-2, eleusis
02:41-!-Netsplit over, joins: eleusis, @Belugas, CIA-2
02:42-!-mode/#openttd [+v Belugas] by ChanServ
02:55-!-_ln [] has joined #openttd
02:59-!-FR^2 [] has joined #openttd
03:13-!-Tekky [] has joined #openttd
03:44-!-maristo [] has joined #openttd
03:48-!-Azrael- [] has joined #openttd
03:50-!-FR^2 [] has quit [Quit: Der Worte sind genug gewechselt, lasst mich auch endlich Taten sehn!]
03:54-!-Svish [~Svish@] has joined #openttd
03:58-!-Svish [~Svish@] has quit [Quit: Leaving]
03:59-!-Progman [] has joined #openttd
04:01-!-ecke [~ecke@] has joined #openttd
04:05-!-|Jeroen| [] has joined #openttd
04:10-!-Alberth [] has joined #openttd
04:12-!-FR^2 [] has joined #openttd
04:19-!-ecke [~ecke@] has quit [Quit: ecke]
04:55-!-frosch123 [] has joined #openttd
05:16-!-Coco-Banana-Man [] has joined #openttd
05:25-!-tokai [] has quit [Ping timeout: 480 seconds]
05:27-!-tokai [] has joined #openttd
05:27-!-mode/#openttd [+v tokai] by ChanServ
05:36-!-yorick [] has joined #openttd
05:39-!-fonsinchen [] has joined #openttd
05:40-!-ecke [~ecke@] has joined #openttd
05:43-!-George3 [~George@] has joined #openttd
05:49-!-George [~George@] has quit [Ping timeout: 480 seconds]
06:05-!-Mucht [] has quit [Remote host closed the connection]
06:10-!-Exl [] has joined #openttd
06:13-!-Tekky_ [] has joined #openttd
06:13-!-Tekky [] has quit [Read error: Connection reset by peer]
06:13-!-Tekky_ is now known as Tekky
06:21-!-Progman [] has quit [Remote host closed the connection]
06:26-!-dfox [] has quit [Ping timeout: 480 seconds]
06:51-!-KenjiE20 [~KenjiE20@] has joined #openttd
06:53-!-thingwath [~thingwath@] has quit [Quit: It's all over.]
07:01-!-Polygon [] has joined #openttd
07:04-!-|Jeroen| [] has quit [Quit: oO]
07:06-!-fjb [] has joined #openttd
07:11-!-DJ-Burtybob [burtybob@] has joined #openttd
07:17-!-Mucht [] has joined #openttd
07:25-!-Wolfensteijn [] has quit [Quit: Changing server]
07:26-!-wolfy [] has joined #openttd
07:27-!-Chruker [] has joined #openttd
07:28-!-jolteon [] has joined #openttd
07:28<jolteon>hai, quick question.
07:28<jolteon>How can I stop my trains reporting as being "lost", when actually it's just in a station loading?
07:29-!-jolteon is now known as Jolteon
07:29<Chruker>Are you sure its not just old messages that have been waiting in the queue to be displayed?
07:29-!-dfox [] has joined #openttd
07:31<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.
07:31<Jolteon>(or a way to tell how long they've been waiting)
07:32-!-[com]buster [] has joined #openttd
07:32-!-[com]buster is "*" on #openttd @+#openttdcoop
07:32<[com]buster>Hi all
07:32<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.
07:33<Jolteon>hmm, i'll try reducing some to off then
07:35<[com]buster>Some tech question
07:35<[com]buster>what things are done every 4 days?
07:35<[com]buster>or at least computed?
07:35-!-Jolteon [] has left #openttd []
07:35-!-Mucht [] has quit [Remote host closed the connection]
07:35-!-Polygon [] has quit [Quit: Verlassend]
07:36<[com]buster>I notice framedrops exactly at each 4-day interval
07:38<@SmatZ>ah, fRamedrops
07:38<@SmatZ>err, 250-ticks
07:39<[com]buster>if that many ticks correspond to ~4 game days
07:39<@SmatZ>roughly, yes
07:39<@SmatZ>station "big tick" iirc
07:39<@SmatZ>and probably other newgrf stuff
07:39<@SmatZ>recomputing station acceptance
07:41*[com]buster thinks that last one's killing the current openttdcoop game :/
07:42<@SmatZ>it's lagging every 3,5 days?
07:43<[com]buster>it is
07:45<[com]buster>Was kindof looking for a way to alleviate the problem
07:46<[com]buster>Don't worry, I'm not spamming tickets for MP support
07:46<[com]buster>yet :)
07:46<yorick>how would it help?
07:46<[com]buster>yorick: I take the map data does not change over the cargo acceptance cycle, no?
07:47<@SmatZ>[com]buster: anyone suggesting that should be muted until he comes with a working multithreaded OTTD :-p
07:47<@SmatZ>and not only 1 thread rendering + 1 thread computations
07:47<[com]buster>I've got some mental plans for multithreaded pathfinding
07:48<@SmatZ>if performance doesn't die on synchronisation :)
07:48<yorick>[com]buster: but industries affect cargo acceptance
07:49<yorick>and also -> multiplayer sync
07:49<[com]buster>Determinism, yes yes yes
07:49<yorick>you'd still have to wait for the cargo acceptance calculations to finished
07:49<[com]buster>I heard all the arguments at least once :)
07:49<yorick>just once?
07:50<[com]buster>at least</quote>
07:50<[com]buster>I've been spammed to death with most obvious ones
07:51<[com]buster>You dev's are a little too predictable in that regard :)
07:51<@SmatZ>yorick's not a dev! :-D
07:51<@SmatZ>not OTTD dev that is
07:51<[com]buster>He acts like one, close enough :)
07:52<yorick>are you comparing me with thát?
07:53-!-Singaporekid [] has joined #openttd
07:53<[com]buster>I think the bottom line is
07:53<[com]buster>you've been brainwashed enough by the ones who *are* devs
07:54<[com]buster>to voice their opinion in their place ;)
07:56-!-glx [glx@2a01:e35:2f59:c7c0:2198:8523:b023:2c79] has joined #openttd
07:56-!-mode/#openttd [+v glx] by ChanServ
07:57<@SmatZ>[com]buster: don't say you disagree with these statements
07:57<@SmatZ>unless you rework a lot of game logic
08:00*[com]buster resists the urge to bounce back the design argument
08:02<Chruker>Need more parralllelllelism in openttd :-)
08:02<yorick>Chruker: you spelled it rong!
08:02<Chruker>And no, I wont just run 4 openttd games at once :-)
08:02<[com]buster>on a quadcore
08:02<[com]buster>that's currently the best thing to do :)
08:03<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
08:03-!-Dred_furst [] has joined #openttd
08:03<[com]buster>Threading *will* come by every other day as it is a hot issue
08:03<[com]buster>independent of openttd
08:04<[com]buster>SmatZ, Am I right that the pathfinder will only bother with *other* trains for a limited distance
08:05<[com]buster>like red signal penalties and block/pbs groups
08:05<[com]buster>and that after some distance, other trains' decision don't affect other trains?
08:06<yorick>they could affect them indirectly
08:06<yorick>using the other trains
08:06<+glx>and pathfinding MUST be deterministic, ie same result at the same time on all clients
08:08<[com]buster>at least you can start with running ship/rv pathfinding on a different core than train pathfinding
08:08<+glx>rv are linked to trains
08:08<yorick>bool NeedResort() --> bool NeedReSort() :)
08:08<yorick>ship pathfinding
08:08<yorick>they don't affect eachother at all
08:09<yorick>but ship pathfinding first needs to be better
08:09<[com]buster>but ship pathfinding of itself is a disjunct operation
08:09<[com]buster>I just wonder, in what way is RV pathfinding linked to rail pathfinding
08:09<@SmatZ>feel free :)
08:09<frosch123>[com]buster: level crossings
08:10<@SmatZ>[com]buster: train path reservation -> level crossings get barred
08:10<+glx>and possible crashes on crossing
08:10<[com]buster>and occupied crossings = PF penalty?
08:11<[com]buster>or at least, different from non-occupied crossings?
08:12<[com]buster>otherwise, the pathfinding is still disjunct
08:14*yorick thinks you could start with gui
08:15<[com]buster>SmatZ once said he already did that
08:15-!-Biolunar [] has joined #openttd
08:15<[com]buster>to something like 10% gain? no?
08:15<@SmatZ>but -10% for uniproc
08:15<yorick>oh, yes, SmatZ did everything
08:15<yorick>SmatZ did 3d openttd
08:16<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
08:17<[com]buster>@yorick: That's one for the fictive get_logical_cpu_count() function :)
08:17<[com]buster>which you'd need for this kind of stuff anyway
08:18<yorick>or go remove everything gui from dedicated servers
08:18<frosch123>excellent suggestion
08:18<yorick>compiles twice as fast, might be twice as small
08:19<yorick>and might be not faster
08:19<[com]buster>dedicated servers should not be faster than the clients
08:19<[com]buster>gets everybody kicked
08:19<frosch123>yorick: you know about the "dedicated" video driver?
08:19<yorick>there's some tick limit :)
08:19<yorick>frosch123: that's the one that displays absolutely nothing?
08:19<[com]buster>yorick: ?
08:20<yorick>[com]buster: ?
08:20<[com]buster>[14:19] <yorick> there's some tick limit :) <- ?
08:20<@SmatZ>[com]buster: ?
08:20<Ammler>[com]buster: why not ask intel to make more powerful single cpus?
08:20<@SmatZ>they are faster when the game is huge
08:20<Ammler>might be easier
08:20<@SmatZ>because they don't have to draw anything
08:20<@SmatZ>but that's clear to you :)
08:20<yorick>SmatZ: but the gui part is still compiled
08:21<yorick>if you manage to separate, it could be a bit easier to thread
08:21<frosch123>Ammler: why not wait until everyone uses multicore with some posix-sufficient os. might be easier
08:21<[com]buster>Ammler, TBH it is not about what Intel will do, but what we will do
08:21<[com]buster>and we all know its going towards more and more and more cores
08:21<[com]buster>and not clock cycles
08:21<Ammler>hehe ";-)"
08:22<[com]buster>btw, xxx's processor lead is only temporary, as history has proved a few times too often
08:24<[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?
08:24<yorick>[com]buster: that's the clients fault
08:25<@SmatZ>[com]buster: actually, when client's late, it doesn't do rendering
08:25<@SmatZ>until it "catches up" with the server
08:25<[com]buster>I know
08:25<[com]buster>[14:19] <[com]buster> dedicated servers should not be faster than the clients
08:25<[com]buster>[14:19] <[com]buster> gets everybody kicked
08:25<@SmatZ>or don't play such huge maps :)
08:25<yorick>so you slow down your servers so the clients can catch up
08:25<yorick>you're strange
08:25<[com]buster>more like
08:25<yorick>just put your server on a limit then
08:26<[com]buster>allow anybody without the latest Pentium 1337 to play
08:26<yorick>they can play
08:26<[com]buster>no they can't
08:26<yorick>until they can't keep up with (72?) ticks per second
08:26<[com]buster>I think SmatZ knows the problem that maps get stopped because *nobody* is able to keep up with the server
08:27-!-MizardX [] has quit [Read error: Connection reset by peer]
08:27<yorick>then you have a too big game
08:27-!-MizardX [] has joined #openttd
08:27<yorick>or a too small client
08:28<[com]buster>A dev's disclaimer
08:28<[com]buster>I thought you were fans of usability, no? 'o.o'
08:28<yorick>I'm not a dev! :-D
08:29<@SmatZ>[com]buster: yeah, I know that problem
08:29<[com]buster>[13:51] <[com]buster> He acts like one, close enough :)
08:29<yorick>first separate, then thread
08:29<@SmatZ>but I have better CPU than the server
08:29<@SmatZ>so I don't mind
08:29<@SmatZ>joking ;)
08:29<@SmatZ>but well, if someone joins with 500MHz CPU
08:29<@SmatZ>you can't slow down the server because of that
08:29<@SmatZ>and make it unplayable for everyone
08:29<yorick>so every dev that agrees I act like one, raise hand
08:30<[com]buster>unfair when the majority's asleep
08:30<yorick>the majority is asleep at 14:30?
08:30<[com]buster>I see only SmatZ talk...
08:30<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?
08:30<yorick>fonsinchen: isn't that on the wiki?
08:30<TrueBrain>fonsinchen: a lot of time
08:32*[com]buster goes to make a ticket for slowing down game speed by a certain amount
08:33-!-Akoz [] has quit [Ping timeout: 480 seconds]
08:33*TrueBrain wonders how playable a game would be at 1 tick per second .. just to keep up with my 50 MHz machine :)
08:33<[com]buster>Exxagerating is an art
08:33<[com]buster>and an annoying one too :(
08:34<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? :)
08:34<[com]buster>I mean like, slow down a Xeon to a P4's speed
08:34<yorick>erm, with avoiding code duplication*
08:34<TrueBrain>ghehe @ yorick
08:36-!-fonsinchen [] has quit [Remote host closed the connection]
08:38<TrueBrain>planetmaker: nice, that image in your signature whichs shows last commit of OpenGFX
08:39<yorick>TrueBrain: I have one with world airliner set :-)
08:42<frosch123>except it is not the latest commit
08:42<frosch123>mabye the latest done by him :)
08:43<yorick>no, planetmakers should be the latest
08:43<yorick>or the rss feed is borken
08:44<frosch123>yeah, somehow the opengfx log mixes commits and flysprayish-activities
08:44<yorick>frosch123: you're looking at the activity log
08:44<yorick>the rss feed is generated by hgweb
08:44<yorick>but mine is better :-)
08:44<TrueBrain>mine is bigger
08:45<frosch123>are you friends of sirkoz?
08:45<Ammler>frosch123: everyone is :-)
08:46<frosch123>did he already release BetterGfx ß
08:46<frosch123>can i somehow install a permanent search-replace to what i type?
08:47<yorick>you can try to pipe to sed
08:48-!-KritiK [] has joined #openttd
08:48-!-fjb [] has quit [Remote host closed the connection]
08:48<TrueBrain>frosch123: /ignore?
08:49<frosch123>but that can only do "/frosch/ D"
08:49<TrueBrain>sounds to me like a permanent search-replace action ;)
08:50<frosch123>and it works, doesn't it ?
08:50<TrueBrain>no idea, never tried :p
08:51<TrueBrain>I wish there was a good IDE for linux for C projects .... blegh
08:51<frosch123>just not inside worßds
08:51<yorick>I did, it doens't :-)
08:51<TrueBrain>credit to MS, MSVC really works as IDE :(
08:51<yorick>s/ns/sn/ :(
08:51<TrueBrain>you all suck!
08:51<Ammler>TrueBrain: didn't you try KDevelop? - So, it failed?
08:51<yorick>who needs IDEs
08:51<TrueBrain>kdevelop is one crappy piece of software :(
08:52<TrueBrain>maybe it got better in the last year ...
08:52<frosch123>ok, forgot to tick "regular expression", works also in words
08:53<Ammler>TrueBrain: netbeans?
08:53<TrueBrain>never tried it .. I stopped reading after 'Java'
08:53<TrueBrain>maybe I should put that issue aside ..
08:54<frosch123>TrueBrain: define "good IDE"
08:54<Ammler>well, I use those tools too less to give you serious comments ;-)
08:54<TrueBrain>frosch123: well .. for one, it should be able to compile what I tell him to
08:54<TrueBrain>it should allow you to open files in a normal way
08:54<TrueBrain>have project support
08:54<TrueBrain>and don't crash on random intervals
08:55<TrueBrain>(which means kdevelop, kate, kwrite, vi already fail)
08:55<frosch123>project support :/ never saw a worst invention
08:55<Ammler>TrueBrain: which KDE did you use as you tested those?
08:55<TrueBrain>I don't use KDE
08:55<TrueBrain>but KDE-libs 3.something and 4.0 and now 4.1
08:55<TrueBrain>or even 4.2 ... hmm ..
08:55<TrueBrain>I will give kdevelop another spin soon
08:55<Ammler>will 4.2 is the first useable kde3
08:55<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
08:56<Ammler>and well* :-P
08:56<frosch123>TrueBrain: I work on too many projects to set up project files for all of them :p
08:57<TrueBrain>frosch123: well 'setting up' is a big word
08:57<TrueBrain>I just want to start a new project, give a dir, and be done with it :p
08:57<TrueBrain>it is mostly for dir + open files :p I dislike browsing ...
08:57<Ammler>all, what kdevelop does, but well, I work too less with it.
08:57<TrueBrain>what kdevelop does, yes, but thatone kept on crashing :p
08:58<Ammler>I used it with kde3.5
08:58<Ammler>which is imo, very stable.
08:58<yorick>ooh, GetStringHeight :-)
08:58<frosch123>hmm, kdevelop. kdevelop's grepping is weird, I prefer kate's
08:58<TrueBrain>frosch123: yup, you are absolutely right
08:58<TrueBrain>just kate fucks up from time to time
08:58<TrueBrain>telling me there are no matches
08:58<dihedral>which woman does not fuck up?
08:58<TrueBrain>while I am standing near one
08:58<frosch123>never did for me
08:59<TrueBrain>happens a bit too often lately :(
08:59<TrueBrain>dihedral: women fuck, not fuck up (or so I hope)
08:59<dihedral>they do both?
08:59<TrueBrain>you know nothing about the first :p
08:59<dihedral>that's what YOU think ^^
08:59<frosch123>just you cannot help kate's grepping to ignore .svn resp. I don't know how
09:00<frosch123>s/help/tell/ :s
09:00<TrueBrain>I guess I can give netbeans a god ..
09:00-!-Akoz [] has joined #openttd
09:00-!-OwenS [] has joined #openttd
09:00<frosch123>oh, and a good ide shall start up in less than a second
09:01<TrueBrain>that too
09:01<frosch123>on my machine :p
09:01<TrueBrain>113 packets needed to install netbeans .....
09:02<frosch123>so it will likely not start up in less than a second :p
09:02<TrueBrain>Gentoo wants to compile from source
09:02<TrueBrain>not always the best way ;)
09:02<frosch123>but it works :)
09:02<frosch123>no problems like missing shared libs or so
09:02<TrueBrain>very true
09:02<TrueBrain>but 113 packets?
09:03<TrueBrain>and the download of netbeans website doesn't work :p
09:03-!-Tekky_ [] has joined #openttd
09:03<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 )
09:03<TrueBrain>OwenS: I use the latter currently ... annoys the hell out of me
09:03<TrueBrain>(mostly because going to an error takes too much time and effort)
09:03<TrueBrain>wrong window ;)
09:04<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
09:05<frosch123>are you using fwv2 with immediate focus stealing via mouse?
09:05<TrueBrain>I hate those desktops! HELL NO! :)
09:05<frosch123>hmm, it is called fvwm, right?
09:05<TrueBrain>I use xfce4, which has one nasty thing, that you can operate a window with your mouse, without giving it the focus
09:06<TrueBrain>it confuses me from time to time
09:06<TrueBrain>adding that I have 2 (wide) screens, doesn't help in detecting where the blue bar is :p
09:07<OwenS>No; KDE4, no immediate focus stealing. Doesn't help though since Yakuake doesn't have a nice highlight bar :p
09:07<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"
09:08<TrueBrain>xfce4 has one 'nasty' thing with autofocus: when the firefox auto-search thing drops, it focuses the window
09:08-!-Tekky [] has quit [Ping timeout: 480 seconds]
09:09-!-Tekky_ is now known as Tekky
09:09<TrueBrain>while typing, it casues the auto-search to popup again
09:09<TrueBrain>and you can keep on going like that for a few minutes :p
09:10<OwenS>I've never been a fan of GTK... probably related to the very evil file chooser
09:13*frosch123 dislikes words starting with "g". you never know whether they refer to gnu, gnome, gimp, ...
09:13<OwenS>At least as of late KDE has stopped naming everything KName
09:13<frosch123>well, some also use Kame
09:14<OwenS>Though avoiding starting them with g (Looking at you, GwenView) would avoid making me think they were Gnome apps
09:15<TrueBrain>I hate most that software that puts 'open' before open source projects
09:15<TrueBrain>so very annoying
09:15-!-Zahl [] has joined #openttd
09:16<frosch123>yeah, only stuff starting with # or ! is worse
09:16-!-reldred [~reldred@] has quit [Read error: Connection reset by peer]
09:18<Ammler>frosch123: like amaroK
09:19<frosch123>s/: like/ likes/
09:19-!-planetmaker [] has left #openttd []
09:20-!-FR^2 [] has quit [Quit: Der Worte sind genug gewechselt, lasst mich auch endlich Taten sehn!]
09:20<Ammler>which "music manager" do the GNOME people use?
09:21<frosch123>I use it as player, not as manager. music managers are as bad as project files
09:23-!-Fuco [] has joined #openttd
09:26<TrueBrain>on that, I agree :)
09:26<Ammler>well, I use it to clean up file system, too.
09:27<frosch123>can it also clean up /usr/portage/distfiles ?
09:28<Ammler>don't have that in my media share :-)
09:28<OwenS>I use Amarok as a media manager. I quite often have to retag files :p
09:29<TrueBrain>retagging via Picard (or rather, my automated scripts) via MusicBrainz
09:29<TrueBrain>no human interaction requires .. and no stupid player
09:30<Ammler>well, I like it how it has always the lyrics and wikipedia and such around, specially if you listen something new.
09:31<OwenS>Which Amarok version?
09:31<@SmatZ>my keyboard stopped working
09:31<@SmatZ>so I hit it
09:31<@SmatZ>several times
09:31<Ammler>oh, I am kinda behind, 1.4
09:31<@SmatZ>now my hands are bleeding
09:31<@SmatZ>and it's still not working :-/
09:32<TrueBrain>SmatZ: then ... why are you typing?
09:32<OwenS>Ammler: Heh, at least you didn't have to fiddle with the Amarok 2.0 alphas :p
09:32<@SmatZ>TrueBrain: different computer :)
09:32<Ammler>openttd is one of the rarly used alphas here.
09:33<Ammler>is used kde3.5 until a month back.
09:33<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)
09:33<Ammler>frosch123: I could use your autoSed too ;-)
09:34<@SmatZ>hmm should I upgrade to KDE4 at computers with ~300MHz and ~GeForce2 ?
09:34<OwenS>KDE4 is lighter than KDE3 in my experience
09:34<frosch123>Ammler: I found a sed-like setting in konversation :)
09:35<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
09:36<TrueBrain>SmatZ: distcc
09:36<OwenS>Though my current box kinda is behind the times.
09:37<@SmatZ>TrueBrain: problem isn't compiling, I can let emerge run for weeks :)
09:37<TrueBrain>ah, 'should I', misread you there :)
09:37<TrueBrain>my mistake ;)
09:37<OwenS>I don't understand how people have the patience to use Gento with all it's compiling :p
09:37<TrueBrain>the stability you get in return ....
09:38<OwenS>I've not noticed any lack of stability :p
09:38*frosch123 likes it default settings
09:38<TrueBrain>that too .. I like the vim settings too :)
09:39<TrueBrain>I can't work with debian vim :(
09:39<OwenS>Heck, last time i experienced unstability it was nVIDIA who were to blame :p
09:39<frosch123>(as weird as that may sound for a gentoo system)
09:39-!-planetmaker [] has joined #openttd
09:39-!-planetmaker is "Ingo von Borstel" on #openttd @+#openttdcoop #openttdcoop.devzone @#openttdcoop.association #tycoon @+#coopetition #openttd.notice #openttd.nightly @+#wwottdgd #openttd.noai
09:39<@SmatZ>I like Win+D works in Gentoo's KDE ;)
09:39<TrueBrain>welcome back planetmaker
09:39<@SmatZ>hello planetmaker!
09:39<planetmaker>hi :-)
09:39<@SmatZ>where have you been?
09:40<planetmaker>running to not be exposed to a thunderstorm :-)
09:40<planetmaker>And I hit the wrong keys when closing chatzilla.
09:40<planetmaker>Closing this channel instead of the app
09:40<OwenS>Haha. I recently got stuck in a thunderstorm for an hour or two :p
09:40<frosch123>he, Ammler: don't molest my client
09:42<Ammler>I wondered, if you already updated to KDE4 Konversation
09:42<OwenS>Ooh, they finally ported it?
09:42<frosch123>i'm on 3.5.10
09:43<Ammler>OwenS: still alpha
09:43<TrueBrain>3.5.10 here too
09:43*SmatZ molested Ammler's client
09:43<@SmatZ>3.5.10 here
09:43<OwenS>I can't stand 3.5 any more... Alt+F2 is useless in it, and theres no program menu search :p
09:43<OwenS>Oh yeah, and it consumes unholy quantities of RAM
09:44<@SmatZ>what should Alt+F2 do?
09:44<Ammler>app start
09:44<Ammler>or <->
09:44<OwenS>In KDE3, brings up the run window; in KDE4, brings up a much more useful launcher
09:44<@SmatZ>enjoy :)
09:44<OwenS>I'm too used to Alt+F2ing and F12ing
09:45<@SmatZ>I am using K menu for everything
09:45<@SmatZ>or I run Konsole and start apps from there
09:45<OwenS>Flaah. Starting Konsole takes too long. Yakuake FTW
09:45<planetmaker>hm... 3.5.9 here :-P
09:45<@SmatZ>outdated planetmaker is outdated :-p
09:46<frosch123>it takes some time to make a planet
09:46<planetmaker>haha :-)
09:46<planetmaker>indeed. But it's a matter of perspective ;)
09:46<planetmaker>Could be considered short, too :-P
09:46<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
09:47<planetmaker>my KDE is of limited stability :S
09:47<@SmatZ>OwenS: for me, having GF8600GT on my main computer, it wasn't usable
09:47<@SmatZ>I even installed it, but those 5fps made me quickly get back to 3.5
09:47<@SmatZ>it's most likely fixed now :)
09:48<OwenS>I believe Alt+F12 or something like that turned off compositing
09:48<OwenS>As of now, though, it should run on pretty much any GPU - and if it doesn't, will disable compositing
09:49<@SmatZ>I searched for solution, but failed... I everytime found only questions regarding 8600's performance
09:49<@SmatZ>or maybe compositing couldn't be disabled those times...
09:50<OwenS>I still don't understand why nVIDIA haven't heard of underclocking in their Linux drivers though
09:51<@SmatZ>OwenS: seems to work for me
09:51<@SmatZ>with Coolbits
09:51<@SmatZ>it doesn't have multiple power profiles though
09:51<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
09:59<[com]buster>Jotted down a prototye for *efficient* multithreaded pathfinding
10:00<[com]buster>People interested in an openoffice draw doc?
10:01<[com]buster>a sec while I upload it
10:01<OwenS>Is it OpenOffice or is there an OpenDocument spec for that now?
10:01<planetmaker>though it's a rather peculiar format. You could export pdf.
10:01<OwenS>And if there is an OpenDocument spec for it - why not just use SVG?!
10:01<[com]buster>and blow up filesize? :)
10:01<[com]buster>just quit using MS office
10:01<OwenS>PDFs aren't big...
10:01<planetmaker>indeed. pdfs are actually ziped (or something)
10:02<yorick>or just use a plain text file
10:02<OwenS>LZW I think
10:02<yorick>with linux line endings :-)
10:02-!-Pygma [~quassel@] has joined #openttd
10:02<yorick>and uft-8 text
10:03<[com]buster>does openoffice _draw_ mean anything?
10:03<[com]buster>utf-8 lol
10:04<OwenS>Wow, that document remi9nded me that OpenOffice still hasn't heard of Anti Aliasing...
10:05<[com]buster>It does when you export ;)
10:05-!-HerzogDeXtEr1 [~Flex@] has joined #openttd
10:05-!-Zorn [] has joined #openttd
10:05<[com]buster>but that was not the point
10:05<OwenS>Thats more an aspect of the format viewer though
10:05<[com]buster> <- pdf for the whores
10:06<OwenS>Okular's a much better viewer anyway :p
10:06<yorick>it's slow
10:06<OwenS>Though your server is slow :p
10:06<[com]buster>that's not it
10:07<[com]buster>my bittorrent is using 90% of the uplink :/
10:07<yorick>but your dependencies have dependencies
10:07<yorick>and they have dependencies
10:07<yorick>and they have dependencies
10:07<yorick>and signal lookahead
10:07<[com]buster>Read dammit
10:08*yorick would like to see a working non-desyncing faster patch
10:09<[com]buster>the thing is determinism
10:09<planetmaker>combuster: but pathfinding is not a local thing but a global one...
10:09<OwenS>[com]buster: So's mine incidentally
10:09<[com]buster>it is network analysis
10:09<yorick>show me a faster, working, non-desyncing example
10:10<OwenS>[com]buster: But I tend to serve files off my fast, in a data center server :p
10:10<[com]buster>it works by redefining the order in which units are pathfinded
10:10<[com]buster>that order is determinate
10:10<yorick>then show me...
10:10<[com]buster>it does however delay dependencies in a huge way
10:10*yorick will not listen until there's a working patch
10:11*[com]buster breaks out the slapping rod and looks sternly at yorick
10:11<[com]buster>\slap ftw
10:11<TrueBrain>[com]buster: what do you mean with: "trains can be multithreaded"?
10:11*yorick gets a slapping shield
10:11-!-HerzogDeXtEr [~Flex@] has quit [Ping timeout: 480 seconds]
10:11<[com]buster>the execution of the pathfinder on each train
10:12<yorick>wouldn't 4 be dependent on 5 via train 6 then
10:12<TrueBrain>as long as you block the rest of the game, you should be fine
10:12<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
10:12<TrueBrain>I only doubt that hte extra CPU required to do this calculation would result in any positive gain by this solution
10:12<[com]buster>you will still have to sync the start and end of the pathfinder
10:12<yorick>better implement better caching
10:12<[com]buster>true, do not attempt on singlecores
10:13<TrueBrain>(remember that PF is only done when a train enters a junction)
10: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
10:13<TrueBrain>say .. 300 or so
10:13<yorick>yapf isn't fast enough for you
10:13<Akoz>truebrain: make it trigger when you have >1k trains then :)
10:13<TrueBrain>so I don't think this is worth any effort of implementing :(
10:13<[com]buster>Truebrain: and block/pbs signals?
10:13<planetmaker>TrueBrain, for low amounts possibly. But for low amounts it's not important as they don't hit any limits anyway
10:14<yorick>also, TrueBrain, you know people are complaining about the speed of the squirrel pathfinder? :-P
10:14<TrueBrain>planetmaker: the point is you make low amounts SLOWER
10:14<planetmaker>TrueBrain, yes, I understood that
10:14<[com]buster>TrueBrain: good optmisation improves the worst case
10:14<planetmaker>My point is: for low amounts a bit slow down is not harmful
10:14<TrueBrain>in all scenarios it is very bad to make a whole game slower, to gain speed in some exsentric situation ;)
10:14<planetmaker>Because no computer limit is reached there
10:15<TrueBrain>planetmaker: bad policy :)
10:15<TrueBrain>what Akoz suggests would be the only 'sane' thing to do
10:15<TrueBrain>but then I say: not worth the effort :)
10:15<planetmaker>TrueBrain, well, depends, IMO
10:15<Akoz>as long as someone else is doing the effort part it's worth it to me!
10:15<TrueBrain>just stating my opinion, feel free to implement it :)
10:15<TrueBrain>I would never keep any of you to implement anything :)
10:15<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)
10:16<planetmaker>or a game which is optimized for low numbers
10:16<Akoz>I had to disbandon a game the other day cause my computer couldn't keep the pace when we got 1500 trains
10:16<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 ;)
10:16<TrueBrain>planetmaker: 'low' numbers in this case are 95% of the users ;)
10:16<@SmatZ>[com]buster: every access to "volatile area" needs to be synchronised, and that's very expensive
10:16<TrueBrain>above the 1000 trains, the game starts to stall on an average pc ;)
10:17<yorick>pathfinding is quite not the good thing to optimize, methinks
10:17<planetmaker>TrueBrain, but the questions are:
10:17<[com]buster>SmatZ: read on
10:17<planetmaker>a) how big is the slow down relative and absolute
10:17<yorick>better optimize stations and acceptance
10:17<TrueBrain>[com]buster: I considered implementing OSPF in OpenTTD ;)
10:17<planetmaker>b) which vehicle number is approx break even
10:17<yorick>yes, go optimize station ticks
10:17<TrueBrain>planetmaker: didn't I say that? :)
10:17<planetmaker>c) is that vehicle number sufficiently low to justify that change
10:17<TrueBrain>and that my guess is that it wouldn't hold :)
10:17<planetmaker>c) is actually the interesting question
10:18<OwenS>TrueBrain: Mmmh, OSPF
10:18<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
10:18<TrueBrain>[16:13] <TrueBrain> say .. 300 or so
10:18<TrueBrain>planetmaker: exactly what I say (give or take a few words) :)
10:18<TrueBrain>but .. implement it, and we can benchmark it ;)
10:18<Ammler>he, maybe you could make one core per company, but then, it will have troubles with sharing patch.
10:18-!-Tekky_ [] has joined #openttd
10:19<Ammler>and it wouldn't help coop
10:19<[com]buster>The approach turns trains into batches
10:19<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
10:19<[com]buster>you only need to synchronize for a single batch
10:19<OwenS>TrueBrain: Perhaps BGP then? :p
10:19<TrueBrain>OwenS: LOL! No :p
10:20<[com]buster>The thing I was considering
10:21<[com]buster>part of the network analysis is also used by YAPF
10:22<TrueBrain>[com]buster: isn't calculating such depgraph (on every track layout change) not really expensive?
10:23<[com]buster>it is limited
10:23<[com]buster>any change can only modify atmost three objects
10:23<TrueBrain>mostly I wonder about merging the nodes
10:23<TrueBrain>page 2, first image, 6 nodes becomes 1 node in the second image
10:24<TrueBrain>keeping in mind TT players are not that good in designing good junctions, how do you know it is 1 single node?
10:24<[com]buster>it is one node because the area of effect reaches the other nodes in the junction
10:24-!-Tekky [] has quit [Ping timeout: 480 seconds]
10:24-!-Tekky_ is now known as Tekky
10:25<[com]buster>i.e. smaller than the signal lookahead
10:25<[com]buster>the one thing the algorithm does
10:25<TrueBrain>in that cast the most left node should be merged with it too :p
10:25<TrueBrain>cast = case :p
10:25-!-Progman [] has joined #openttd
10:25<[com]buster>the signal lookahead is too large indeed
10:26<[com]buster>iirc it was 10
10:26<[com]buster>but the point is,
10:26<@SmatZ>10 is max, 2 is default i think
10:27-!-Tekky_ [] has joined #openttd
10:29<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
10:29<TrueBrain>[com]buster: might be an interesting project to start, but I think the outcome is depressing ..
10:29<[com]buster>Even if you do stupid graphing
10:29<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)
10:30-!-DephNet[Paul] [] has quit [Ping timeout: 480 seconds]
10:30<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
10:31<TrueBrain>I sure hope you won't create more cores than the user owns
10:31-!-orudge` [~orudge@] has joined #openttd
10:31-!-mode/#openttd [+o orudge`] by ChanServ
10:31-!-sdafsdf [] has joined #openttd
10:31-!-LadyHawk [] has quit [Read error: Connection reset by peer]
10:32-!-sdafsdf is now known as LadyHawk
10:32-!-[alt]buster [] has joined #openttd
10:32-!-Tekky [] has quit [Ping timeout: 480 seconds]
10:33-!-maristo [] has quit [Remote host closed the connection]
10:33-!-Tekky_ is now known as Tekky
10:33<[alt]buster>Bottom line of the approach is
10:33<[alt]buster>divide the net in N pieces
10:34<[alt]buster>group the vehicles that affect only one piece, and execute the pieces concurrently
10:34<[alt]buster>then execute the vehicles crossing multiple pieces
10:35<[alt]buster>for all I care, use the X coordinate
10:36<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 :)
10:37<TrueBrain>nevertheless, I think the idea is nice and nifty :)
10:38-!-[com]buster [] has quit [Ping timeout: 480 seconds]
10:38-!-[alt]buster is now known as [com]buster
10:39<[com]buster>Glad someone appreciates it :)
10:39<TrueBrain>I like thinking out-of-the-box (which this is)
10:40-!-orudge` [~orudge@] has quit []
10:41<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)
10:41<TrueBrain>it just consumes more memory :p
10:42<[com]buster>Its like the improved pathfinder, no?
10:42<[com]buster>in running time that is
10:43<TrueBrain>OSPF is a network technoligy
10:43<TrueBrain>how routers inside your ISP know and find eachother
10:43<OwenS>Open Shortest Path First
10:43<TrueBrain>basicly, each node knows which nodes to send data to reach a given destination the fastest
10:43<TrueBrain>when a link utilizes, other links would be used
10:43-!-orudge` [~orudge@] has joined #openttd
10:43-!-mode/#openttd [+o orudge`] by ChanServ
10:44<TrueBrain>(although in netwoking, the latter only happens when you utilize, say, above 80% or so)
10:44<OwenS>Crap I'm TVTroping on IRC...
10:44<TrueBrain>in the old days on the internet each node had a big table about all other nodes, so a n^n table
10:44<TrueBrain>OSPF is a tiny bit more clever ;)
10:46<OwenS>Yeah. Intra-ISP, OSPF; Inter-ISP, eBGP
10:47<TrueBrain>one can also consider BGP, but BGP is a push protocol, where OSPF is a flood protocol
10:47<OwenS>On the plus side, OpenTTD wouldn't have flapping problems
10:48<TrueBrain>no unannounced dead links
10:48<TrueBrain>lovely, a perfect world
10:49<OwenS>No AS 7007 incidents
10:51-!-DJ-Burtybob [burtybob@] has quit [Ping timeout: 480 seconds]
10:58*yorick is surprised there is no SmallVector::iterator
11:07<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"?
11:07<Eddi|zuHause>preferably a single command line ;)
11:08-!-Singaporekid [] has quit [Quit: Leaving]
11:10<TrueBrain>pff, netbeans still isn't installed :(
11:10<frosch123> /A$/ { N; /B$/ { N; /C$/ { p; .... plus some branches and deletes
11:17-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
11:18<CIA-2>OpenTTD: alberth * r16878 /trunk/src/rail_gui.cpp: -Codechange: Let WWT_LABEL widgets do the drawing rather than OnPaint.
11:19-!-JFBelugas [] has joined #openttd
11:22-!-TheMask96 [] has joined #openttd
11:23<TrueBrain>finally, netbeans is installed ... but I am already done with my project of the day :(
11:25<TrueBrain>I think I forgot to install C++ for netbeans .... :s
11:29<Eddi|zuHause>the translation system of Civ4 is stupid...
11:30<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
11:30<TrueBrain>isn't civ4 paid software, which has the translation for you?
11:31<Eddi|zuHause>yes. but it is "open source", so people can provide mods
11:31<Eddi|zuHause>and these modders also must provide all translations...
11:31<TrueBrain>maybe something for WT3 :p
11:31*yorick is still waiting for that suggestions feature
11:31<TrueBrain>happy waiting
11:32<yorick>and still concerned my password is not safe on your website :-)
11:32<Eddi|zuHause>if you want to implement XML-handling in WT3, feel free :)
11:32<TrueBrain>no, we steal your password and hack your bankaccount
11:32<yorick>I have no account
11:32<yorick>for that reason
11:32<TrueBrain>that is most likely the most stupiest reason I have ever read
11:32<TrueBrain>you don't have an account, because you are afraid your password is not safe
11:33<TrueBrain>you do know you can use more than one password on the internet?
11:33-!-DephNet[Paul] [] has joined #openttd
11:33<Alberth>maybe you should not have a password instead :p
11:33<yorick>I'll never remember!
11:33<Eddi|zuHause>anyway... now i am searching for all <text>-tags that do not have a <german>-tag
11:33<TrueBrain>really yorick, you just made it to my list of most stupest user ever :p
11:33<yorick>I barely remember my spotify password
11:34-!-DephNet[Paul] [] has quit []
11:34<TrueBrain>yorick: but as our website is in SVN, feel free to check how we store your password
11:34<yorick>it is now?
11:34-!-DephNet[Paul] [] has joined #openttd
11:34<Eddi|zuHause>which are like 10 of 2000, distributed over 20 xml-files
11:34<TrueBrain>but please, if you don't trust us without looking at it, don't sign up
11:34<TrueBrain>and .. please never install the game again
11:35<TrueBrain>Eddi|zuHause: write a script :)
11:36*yorick looks at code
11:36*TrueBrain writes a no-yorick-signup piece of code and commits it
11:37<TrueBrain>Eddi|zuHause: I will consider Civ4 support when I write WT3.1 and release it in a more general form :)
11:37-!-DephNet[Paul] [] has quit []
11:38<yorick>hm, hashtype$salt$hash
11:39<yorick>sha1 hashy
11:39<yorick>and how do I know you haven't patched django
11:39<TrueBrain>yorick: don't signup
11:39<TrueBrain>please don't
11:39<TrueBrain>I can assure you I will distribute your password over the whole web
11:39<TrueBrain>hack all your accounts
11:39<TrueBrain>and make your mom see that video you don't want anyone to see
11:39<TrueBrain>I promise you I will
11:39<yorick>NOT THE VIDEO
11:39-!-DephNet[Paul] [] has joined #openttd
11:40<CIA-2>OpenTTD: alberth * r16879 /trunk/src/rail_gui.cpp: -Codechange: Use coordinates of widgets for custom rendering.
11:41<TrueBrain>and again yorick, please never start the game again
11:41<TrueBrain>I am sure I wrote a backdoor somewhere
11:41<TrueBrain>where I could do the same
11:42<yorick>OH NOES
11:45<_ln>does someone know what's that place with huge satellite dishes in northern netherlands? (somewhere northwest of groningen)
11:45<TrueBrain>VLT, that is huge
11:46<Alberth>hmm, but both are not in Groningen.
11:46<TrueBrain>VLT is not even in this country :p
11:47<_ln>well, not particularly close to Groningen. somewhere in the countryside. 'huge' = 2 times the height of trees near them.
11:49<planetmaker>_ln, not sure, but maybe it's part of the the very low frequency array...
11:49<TrueBrain>that website says it is the biggest, which is a bit of a bullshit :p
11:49<TrueBrain>planetmaker: VLA is in New Mexico
11:50<planetmaker>TrueBrain, not the VLA. That's radio
11:50<TrueBrain>and LOFAR are 1m in height :p
11:50<planetmaker>:-) I thought of that. The name eluded me.
11:50<TrueBrain>friend of mine processed one of the first data from Berlin and back, so somehow I remember that name :p
11:51<planetmaker>a friend of mine works on lofar :-)
11:51<TrueBrain>then they most likely met :p (he has been up and down Germany a few times :p)
11:51<planetmaker>but I wasn't sure that they might have some "conventional" antennae, too
11:51<planetmaker>well... he's there in the Dutch "Pampa" :-P
11:51<TrueBrain>lol, up and down :p
11:52<TrueBrain>either way, LOFAR has more problems launching the project than any images currently :p
11:53<TrueBrain>planetmaker: LOFAR shuold get a big telescope, but as far as I know, it hasn't been built yet :)
11:53<TrueBrain>it started in august last year or something
11:53<_ln>hmm, Westerbork looks basically right, but its location is not consistent with my data.
11:54<TrueBrain>Westerbork hasn't moved over th elast few years
11:55<_ln>we basically drove from Groningen to some small town called 'Anjum', and the dishes were somewhere quite close to the latter one.
11:57<planetmaker>he, yeah.... lofar is not easy to get off the ground...
11:57<TrueBrain>bah, surfnet doesn't have a nice image anymore which shows the amount of traffic over their fibers .. was fun to watch :)
11:58<planetmaker>Yeah, they definitely need state of the art network technology :-)
11:58<TrueBrain>(lofar goes over surfnet fiber network)
11:58<planetmaker>And good real-time computers for data pre-processing
11:59<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.
12:01-!-OwenS [] has quit [Read error: Connection reset by peer]
12:01-!-OwenS [] has joined #openttd
12:04<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.
12:04<Alberth>westerbork has 14 iirc
12:08<Akoz>what is "squirrel" in ottd?
12:08<Eddi|zuHause>the ai scripting language
12:09<Akoz>oh right
12:10<Akoz>could someone move task 3040 to another category for me?
12:10<TrueBrain>at random?
12:11<Akoz>dno. what do you think? :)'
12:11<TrueBrain>:) Hehehe :)
12:11<TrueBrain>I think you should be more specific :)
12:11<Akoz>Im not sure
12:11<Akoz>I guess core?
12:12<Akoz>its gui
12:12-!-paul_ [~paul@] has joined #openttd
12:12<TrueBrain>GUI == Interface
12:12<TrueBrain>what about you?
12:12<Akoz>sounds goods
12:12<Akoz>ty :)
12:12<TrueBrain>np :)
12:13-!-Tekky_ [] has joined #openttd
12:14-!-Tekky [] has quit [Read error: Connection reset by peer]
12:14-!-Tekky_ is now known as Tekky
12:19-!-DephNet[Paul] [] has quit [Ping timeout: 480 seconds]
12:19-!-OwenSX [] has joined #openttd
12:19-!-OwenS is now known as Guest1588
12:19-!-OwenSX is now known as OwenS
12:21-!-paul_ [~paul@] has quit [Quit: Leaving]
12:21-!-DephNet[Paul] [~paul@] has joined #openttd
12:22-!-Guest1588 [] has quit [Ping timeout: 480 seconds]
12:28-!-orudge` [~orudge@] has quit [Ping timeout: 480 seconds]
12:28-!-orudge` [~orudge@] has joined #openttd
12:28-!-mode/#openttd [+o orudge`] by ChanServ
12:38-!-Dragoon_Jett [] has joined #openttd
12:39-!-TheCondor [] has joined #openttd
12:39<Dragoon_Jett>I am new to OTTD, could anyone point me to a website with a lot of custom resources for it
12:40<Dragoon_Jett>I tried google but I am lazy
12:40<Dragoon_Jett>Thanks Ill check these out
12:40-!-OwenS [] has quit [Ping timeout: 480 seconds]
12:40<_ln>get well soon
12:41<TrueBrain>Dragoon_Jett: and welcome to OpenTTD :)
12:43<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
12:43-!-OwenS [] has joined #openttd
12:58-!-Progman [] has quit [Remote host closed the connection]
12:58<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.
13:07-!-TheStarLion [] has joined #openttd
13:09-!-TheStarLion [] has quit []
13:11*planetmaker just wonders: how many orders may a single vehicle have?
13:12<planetmaker>I'm now at 95, but that's definitely less than half of what I need :-)
13:13<TrueBrain>you know that you don't have to give it such amount of orders it needs for his whole lifetime, right?
13:13<TrueBrain>it will go back to order 0 when it reaches the latest :p
13:13<planetmaker>yep. basically.
13:13<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
13:14<planetmaker>But I'll need n! * 5 order entries :-)
13:15<planetmaker>@calc 12!
13:15<@DorpsGek>planetmaker: Error: unexpected EOF while parsing (<string>, line 1)
13:15<planetmaker>yes, I know.
13:15<planetmaker>But saves the hassle to look where trains are missing.
13:15<frosch123>@calc factorial(12)
13:15<@DorpsGek>frosch123: Error: 'factorial' is not a defined function.
13:15<planetmaker>Just add further trains and it will sort out :-)
13:15<DaleStan>12! = 479001600
13:15<TrueBrain>@calc fac(12)
13:15<@DorpsGek>TrueBrain: Error: 'fac' is not a defined function.
13:16<planetmaker>hm... that's a lot...
13:16<planetmaker>hm... wait, it's not factorial...
13:16<_ln>@calc define f (x) { if (x <= 1) return (1); return (f(x-1) * x); } f(12)
13:16<@DorpsGek>_ln: Error: invalid syntax (<string>, line 1)
13:16<TrueBrain>I think you need another approach ;)
13:16<planetmaker>it's sum_i=1^n 5n
13:17<frosch123>planetmaker: however VehicleOrderID is a byte
13:17<TrueBrain>1^n, sounds useful ;)
13:17<planetmaker>frosch123, ok, 254 and no more...
13:17<planetmaker>I assumed so. :-)
13:18<TrueBrain>maybe even 253 .. depends how many IDs are reserved ;)
13:18<planetmaker>hm... I need 390 entries
13:24<planetmaker>I guess I cut some options on low-traffic stations :-)
13:28<CIA-2>OpenTTD: alberth * r16882 /trunk/src/rail_gui.cpp: -Codechange: Introduce a line_height variable in the station picker window.
13:45<CIA-2>OpenTTD: translators * r16883 /trunk/src/lang/ (4 files):
13:45<CIA-2>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-2>OpenTTD: simplified_chinese - 5 changes by Gavin
13:45<CIA-2>OpenTTD: traditional_chinese - 4 changes by ww9980
13:45<CIA-2>OpenTTD: russian - 12 changes by Lone_Wolf
13:45<CIA-2>OpenTTD: slovak - 7 changes by James
13:46-!-fonsinchen [] has joined #openttd
14:33-!-oskari89 [oskari89@] has joined #openttd
14:38-!-Trenskow [] has joined #openttd
14:48-!-paul_ [] has joined #openttd
14:49-!-orudge` [~orudge@] has quit [Ping timeout: 480 seconds]
14:49-!-orudge` [~orudge@] has joined #openttd
14:49-!-mode/#openttd [+o orudge`] by ChanServ
14:50-!-paul_ [] has quit []
14:51-!-paul_ [~paul@] has joined #openttd
14:52-!-DephNet[Paul] [~paul@] has quit [Ping timeout: 480 seconds]
14:53-!-paul_ [~paul@] has quit []
14:55-!-DephNet[Paul] [~paul@] has joined #openttd
14:56-!-orudge`` [~orudge@] has joined #openttd
14:56-!-orudge` [~orudge@] has quit [Read error: Connection reset by peer]
14:56-!-orudge`` is now known as orudge`
14:57-!-Progman [] has joined #openttd
14:57-!-Progman [] has quit [Remote host closed the connection]
15:00-!-Mucht [] has joined #openttd
15:01-!-Progman [] has joined #openttd
15:06-!-kingj is now known as KingJ
15:06-!-Forked [] has quit [Ping timeout: 480 seconds]
15:17<CIA-2>OpenTTD: frosch * r16884 /trunk/src/ (depot_gui.cpp train.h train_cmd.cpp): -Codechange: Add Train::GetFirstEnginePart() and use it.
15:19-!-Trenskow [] has quit [Quit: Trenskow]
15:20<TrueBrain>STUPID NETBEANS! It refuses to allow tabs in the beginning of a line :s
15:21<TrueBrain>oh .. with hitting enter REALLY hard it does ..
15:21<TrueBrain>just it refuses to show it is a \t ..
15:24<frosch123>you have to press enter for tabs ?
15:24<TrueBrain>no, for the settings to store
15:24<TrueBrain>50% of the time or something, it doesn't store my changes
15:24<TrueBrain>dunno why :s
15:26-!-helb [~helb@] has quit [Ping timeout: 480 seconds]
15:29-!-Tekky_ [] has joined #openttd
15:31-!-helb [~helb@] has joined #openttd
15:33<frosch123>and does a java ide satisfy the start-up-in-less-than-a-second criterion?
15:33<TrueBrain>first time not, but next times is relative fast
15:33<TrueBrain>just the tons of plugins you seem to require
15:33<TrueBrain>which all need you to accept a license
15:33<TrueBrain>that is a bit .. less useful
15:34-!-Tekky [] has quit [Ping timeout: 480 seconds]
15:34-!-Tekky_ is now known as Tekky
15:35<TrueBrain>and it notices I have a mercurial checkout
15:35<TrueBrain>which is kind of nice
15:35<TrueBrain>debugger attaches correctly
15:44<fonsinchen>I have a funny desync (with timetable separation and cargodist):
15:44<fonsinchen>If anyone has an idea what that might be, please tell me.
15:46<TrueBrain>the client goes in a train handler routine
15:46<TrueBrain>the server doesn't
15:46<TrueBrain>good luck hunting that down :)
15:46<TrueBrain>this tells you where exactly the desyncs happens
15:46<TrueBrain>the reason for the desync can be burried DEEP
15:46<TrueBrain>very deep ...
15:46<TrueBrain>if you can reproduce it on the same position every time
15:46<TrueBrain>you can figure out which train it is
15:46<TrueBrain>you can figure out the specs of the train
15:47<TrueBrain>and you can figure out what goes wrong :)
15:47<fonsinchen>Well, I run it through valgrind first, hoping that it's a memory management problem ...
15:47<TrueBrain>most likely you 'forget' to sync a variable or what ever
15:48<frosch123>hmm, how do I type a formfeed
15:48<fonsinchen>I don't think there is any hidden state in either timetable separation or cargodist. But of course I may be wrong
15:48<planetmaker>timetable separation actually sounds like states needed
15:49<TrueBrain>nobody said the state has to be hidden :)
15:49<Alberth>frosch123: ^L iirc
15:49<fonsinchen>Have a look at the patch, it doesn't add any fields
15:49<TrueBrain>we had times the problem was hiding in plain sight
15:49<TrueBrain>I never talked about a new field
15:49<TrueBrain>I talked about syncing
15:49<TrueBrain>in other words: the server does A, the client does B
15:49<planetmaker>fonsinchen, it might just be the use of the wrong random (interactive vs. non interactive)
15:49<TrueBrain>because something 'forgot' to tell either one something else changed
15:50<fonsinchen>neither cargodist nor timetable use any random values
15:50<TrueBrain>planetmaker: doesn't look like it, but yeah: possible ;)
15:50<fonsinchen>but what about the syncing
15:50<fonsinchen>what do you mean?
15:50<Alberth>frosch123: \f
15:50<TrueBrain>fonsinchen: if (vehicle.state == VEH_STOPPED) Random(); else NoRandom()
15:50<TrueBrain>if server thinks state is STOPPED, but client thinks it is RUNNING
15:50<TrueBrain>you desync
15:51<fonsinchen>now as vehicle.state is saved that shouldn't be possible
15:51<fonsinchen>or do I have to add any manual syncing anywhere?
15:51<TrueBrain>but if at some point the server changes it, and the client doesn't
15:51<TrueBrain>for what ever reason
15:51<frosch123>Alberth: using echo -e worked :)
15:51<fonsinchen>only possible with random, though
15:52<fonsinchen>or threads
15:52<TrueBrain>random just shows the problem
15:52<TrueBrain>the true problem can be lines deep
15:52<TrueBrain>even hours before it happening, in theory
15:52<TrueBrain>a few desyncs we had in the past were deep .. really deep :p
15:53<TrueBrain>finding out what is a bitch, a real bitch
15:53<TrueBrain>and for all we know, those two patches just make it visible
15:53<planetmaker>hm... there was some configure option for desync debugging afaik.
15:53<TrueBrain>planetmaker: the result you can see in his pastebin :)
15:53<planetmaker>oh, ok :-P
15:53<TrueBrain>in this case it tells us that the client went into handling a train
15:53<TrueBrain>where the server went into handling a town
15:54<fonsinchen>the problem happens just 2 minutes after loading the savegame
15:54<TrueBrain>giving me the strong impression something synced wrong :)
15:54<TrueBrain>example: a train leaves a station in server sooner than in client
15:54<Aali>I remember debugging a desync where cargo packets were loaded slightly different on client/server
15:54<Aali>that was "fun"
15:54<TrueBrain>BE/LE problems
15:54<TrueBrain>fun fun
15:54<TrueBrain>initialization problems
15:55<TrueBrain>I have seen too many desyncs :(
15:55<TrueBrain>(hell, I wrote the initial versions of the desync tracers :p
15:55<fonsinchen>both client and server are running on the same machine - so endianness isn't the problem.
15:55<fonsinchen>missing initialization might be
15:55<TrueBrain>but as I said: find out which train it is
15:55<TrueBrain>dump the content
15:55<TrueBrain>figure out more
15:55<TrueBrain>if you can reproduce it
15:55<TrueBrain>you can trace it
15:56<planetmaker>or initilisation which depends upon time
15:56<planetmaker>can happen nicely with newgrf :-)
15:56<planetmaker>or at least could
15:57<fonsinchen>well, we'll see what I can find out.
15:57<fonsinchen>Thanks for the advice
15:57<planetmaker>May you have success :-)
15:57<planetmaker>quick success
15:57<TrueBrain>rule out as much as possible (grfs, 64bit, ...)
15:58<TrueBrain>and you keep a small list of possibilities :)
15:58<TrueBrain>but I would go for vehicle data at first :)
15:59<Alberth>good night all
15:59<TrueBrain>night Alberth
15:59<TrueBrain>fonsinchen: other mostly useful tips: try reproducing on small maps (64x64)
15:59<TrueBrain>and with as little as possible (1 or 2 trains)
15:59<TrueBrain>avoids ... debug information :p
16:00<Ammler>good night Alberth
16:00<planetmaker>night Albert
16:00-!-Alberth [] has left #openttd []
16:00<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...
16:00<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.
16:01<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.
16:01<TrueBrain>use the searh
16:01<TrueBrain>for your floating point 'suggestion': avoid floating point in any real application
16:01<TrueBrain>floating points are SSLLOOOWWWWWW
16:01<TrueBrain>(and mostly completely unneeded)
16:06<_ln>but good for storing dates as they already contain a dot.
16:06<_ln>(yes, i'm kidding.)
16:07<TrueBrain>forgetting to reset an itimer can have nasty side-effects ... ghehe
16:11<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?
16:11<TrueBrain>I made very clear I was refering to two entries
16:12<TrueBrain>on one side the sync stuff, which has been talked over so many times I refuse to talk about in here
16:12<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
16:12<TrueBrain>it has no use, no extra value, and all physic stuff can be rewritten to use ints
16:14<frosch123>Tekky: btw. how big is a ottd savegame, and how often do you want to transfer it between server and client?
16:14<Tekky>Hmmmm, when I search the OpenTTD Development Forum for the keyword "sync", I am unable to find any such discussion.
16:15<Eddi|zuHause>happens more often in this channel, probably
16:15<TrueBrain>it also happens in most 'desync' threads
16:15<TrueBrain>but okay, Tekky, I am sorry, there is not a dedicated thread for it
16:15<TrueBrain>so let me put it in these words: either read the code, how the network works and stuff, or don't make suggestions :)
16:16<TrueBrain>and sorry if that sounds harsh, but you have no idea how many 'briliant' people came and gave that suggestion
16:16<TrueBrain>like we never thought about it or what ever :p
16:17<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.
16:17<TrueBrain>you guessed wrong
16:18<frosch123>Tekky: so what about building fields, changing industry production, building town roads and houses, building fences on clear tiles, building trees, ...
16:18<TrueBrain>growing trees!
16:18<TrueBrain>(which will be the most bandwidth :p)
16:19<frosch123>TrueBrain: not true, changing animation frames of industries will take more
16:19<TrueBrain>frosch123: but that doesn't need syncing, does it? :)
16:20<frosch123>depends on the grf, for ecs you surely need to
16:20<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?
16:20<TrueBrain>frosch123: fair enough ;)
16:20<frosch123>Tekky: sure, but that only works as long as the clients are in sync
16:22<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 :)
16:22<planetmaker>Tekky, the difference is: commands are player actions. What you want is EVERY change
16:22<TrueBrain>(and that was including all kinds of weird optimizations and shortcuts :p)
16:30-!-Wolle [] has joined #openttd
16:31<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...
16:31<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.
16:31<TrueBrain>I think Tekky will be making us a patch
16:31<TrueBrain>best of luck
16:33<TrueBrain>'unimportant things such as tree growth' .. he clearly has no clue about the game :) Hihi :)
16:33<Tekky>Hehe, yes, I am aware that the whole tree growth algorithm would have to be changed. :)
16:34<TrueBrain>lets change the whole game
16:34<Eddi|zuHause>Tekky: "animation frame" does not necessarily have anything to with animation... some newgrfs use that as some arbitrary memory
16:34<yorick>lets make openttd WITH!!!!! better multiplayer
16:34<TrueBrain>Eddi|zuHause: so lets change that!
16:35<TrueBrain>I think we have to remove most of the GUI too, as that would only give wrong estimations ...
16:35<TrueBrain>hehe: you remove a tile of what you think is a clear tile
16:35<TrueBrain>you see 400,000 going away
16:36<TrueBrain>turns out it was a sea tile now
16:36<TrueBrain>oopsie ... well .. unimportant
16:36<TrueBrain>things you have to live with when you want servers to do the calculations
16:37<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
16:37<OwenS>And transfering all that important data only when it's needed. Good luck. For our current game... Thats about 500kb/s
16:38<TrueBrain>OpenTTD was not built with a server/client model in mind, where freeciv is, for example :)
16:38<OwenS>And I'm being generous here and assuming 70% of the savegame size the clients already have. This is likely not the case
16:38<Chruker>The server should be the only thing with the complete game state. Clients should just be glorified remote windows
16:38<TrueBrain>Chruker: well, in fact, I once explored this theory
16:38<frosch123>indeed, likely it is better to play ottd via a x connection
16:38<yorick>lets make openttd-vnc!
16:38<TrueBrain>to send to a client only a VERY limited view of the map
16:39<TrueBrain>to allow explosive big maps
16:39<TrueBrain>(up to 1Mx1M)
16:39<TrueBrain>it is doable, I can tell you ..
16:39<Eddi|zuHause>OwenS: just send non-deterministically, then you can also use the upload bandwidth of the clients :p
16:39<TrueBrain>just ...
16:39<TrueBrain>it needs a full rewrite
16:39<TrueBrain>but that is a minor detail, I guess
16:39<Chruker>yes, minor :-)
16:39<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...
16:40<Eddi|zuHause>if you are at it, you can also make it multithreaded :p
16:40<TrueBrain>well, 'full rewrite' is not true, you can keep the GUI :)
16:40<Eddi|zuHause>oh, and 3D
16:40<frosch123>or just join #transportempire
16:40<TrueBrain>oh, and make sure it gives me 1M (real) euros every day
16:41<OwenS>And rewrite it all in D beccause D is awesome
16:41<Xaroth>every day?
16:41<Xaroth>greedy bastard, i'd be satisfied with 1m a month :P
16:41<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.
16:42<OwenS>Most similar types of game work the same way. They just don't have this issue because everyone runs the same version
16:42<OwenS>Oh, and TrueBrain, I reject the assertion that floats are slow
16:42<TrueBrain>Xaroth: okay, then you can get 1M every month :p
16:43<Eddi|zuHause>Tekky: you really think that the desyncs are the problem?
16:43<Eddi|zuHause>or are they rather a symptom of deeper problems?
16:43-!-Zorn [] has quit [Read error: Connection reset by peer]
16:43<OwenS>Such as doing stuff in callbacks your not to do such stuff in
16:43<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
16:44<TrueBrain>OwenS: run a loop where you do tons of divides
16:44<TrueBrain>now do the one with floats, the other with ints
16:44<TrueBrain>you tell me which is faster :p
16:44<OwenS>TrueBrain: OK. In this loop, I'll be using SSE. Is this OK? ;-)
16:44<TrueBrain>nope :)
16:45<OwenS>PowerPC Altivec?
16:45<TrueBrain>well, in fact I don't care what you use
16:45<TrueBrain>as long as one uses the FPU, the other the CPU, it is fine by me :p
16:45<Eddi|zuHause>for what platform is openttd (windows) usually compiled? i586? i386?
16:45<TrueBrain>and I know, nowedays the differences are minimal
16:45<TrueBrain>just avoiding float is always a good thing :)
16:45<TrueBrain>Eddi|zuHause: i386, windows doesn't really define i[456]86 or
16:46<TrueBrain>although documentation is vague on the subject
16:46<OwenS>Heck, most computers have more floating point power than integer. It's just all hidden inside the GPU :p
16:46<TrueBrain>OwenS: which assumes you have a GPU worth talking about ;)
16:46<TrueBrain>the reason I say: FPU ;)
16:46<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...
16:46<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.
16:46<OwenS>TrueBrain: Even a crappy GMA beats most CPUs
16:47<TrueBrain>so terrain is important
16:47<TrueBrain>and a moment ago you said tree growth isn't?
16:47<TrueBrain>now you make no sense
16:47<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 ...
16:47<TrueBrain>OwenS: true true
16:47<TrueBrain>fonsinchen: I suspect bad patch
16:47<Eddi|zuHause>Tekky: do you have an idea how many pathfinding decisions are done every tick?
16:47<fonsinchen>of course one of the patches is bad
16:47<fonsinchen>the tricky part is finding out if it's mine or the other
16:48<TrueBrain>fonsinchen: how many vehicles are in the pool?
16:48<fonsinchen>I mean 67 is correct
16:48<fonsinchen>2091 is false
16:48<frosch123>Eddi|zuHause: number of vehicles / 100 ?
16:48<OwenS>Incidentally, random bug: When I throw OpenTTD from one display to another (maximized on both), it doesn't update it's size
16:48<TrueBrain>fonsinchen: sorry, have been out too long of this to give you useful hints and tips
16:48<TrueBrain>fonsinchen: just: make sure to use printf, and not gdb
16:49<TrueBrain>gdb fucks up using optimizations
16:49<TrueBrain>OwenS: ;)
16:49<fonsinchen>The code isn't optimized
16:49<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.
16:49<Eddi|zuHause>i don't know... but let's for the sake of argument use "10" [1000/100]
16:49<fonsinchen>I mean no compiler optimization
16:49<TrueBrain>fonsinchen: you sure? You used -O0? (even then, I wouldn't bet on it :p)
16:49<TrueBrain>believe me, you want to use printf :p
16:49-!-Xeryus|bnc is now known as XeryusTC
16:50<Eddi|zuHause>then for each such decision, the vehicle-ID, the vehicle position (tile, trackbit), and cosen path must be transferred
16:50<TrueBrain>fonsinchen: but okay, I wouldn't know what first_unused indicates, so I can't help you there :) Maybe someone else can :)
16:50<TrueBrain>fonsinchen: but it is a hell of a road, with a lot of guesses and following hunches ...
16:50<fonsinchen>it believes there are 2090 vehicles in the pool, so FOR_ALL_VEHICLES shows zombies
16:50<Eddi|zuHause>let's say that these can be put into 64 bits
16:50<TrueBrain>and in the end, you forgot to assign a value to a static variable or something stupid :p
16:51<TrueBrain>fonsinchen: in the old days the first 2048 vehicles were 'special' vehicles, but ... don't ask me if that still is true :)
16:51<TrueBrain>I wouldn't be able to tell you :)
16:51<TrueBrain>my knowledge is OLD!
16:51<Tekky>Eddi|zuHause: The entire chosen path to the destination does not have to be transferred, only the direction chosen.
16:52<yorick>and 42 happens to be 2x21 :-)
16:52<TrueBrain>7*8, you silly
16:53<TrueBrain>no, 42!!
16:53<TrueBrain>sigh :(
16:53<Eddi|zuHause>but then you have 64bit * 10 decisions per tick * 33 ticks per second, that are about 20kbit/s for the pathfinder alone
16:54<TrueBrain>6 times 9?
16:54<TrueBrain>(see if you can guess right this time :p)
16:54-!-DephNet[Paul] [~paul@] has quit [Read error: Connection reset by peer]
16:54<Eddi|zuHause>#define SIX 1+5
16:55<Eddi|zuHause>#define NINE 8+1
16:55-!-DephNet[Paul] [~paul@] has joined #openttd
16:55*TrueBrain hugs Eddi|zuHause
16:55<TrueBrain>"I refuse to answer that question on the grounds that I don't know the answer. "
16:56<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. "
16:56<TrueBrain>I love thatone :)
16:56<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.
16:57<Tekky>It never made sense to me why most DSL connection have ten times less upload capacity than download capacity.
16:58<TrueBrain>because to download at full speed you need 10% of that speed as upload
16:58<TrueBrain>simple TCP/IP stream calculation (of the old days)
16:58<Eddi|zuHause>that was based on some manager's calculations that most internet users are "passive"
16:58*yorick will get 50mb/s sync
16:58<TrueBrain>has 100 mbit/s up+down
16:58<Eddi|zuHause>that was before torrents were invented :p
16:59<Eddi|zuHause>or... napster...
16:59<TrueBrain>Eddi|zuHause: it still is a truth you need about 1/10th of your download speed as upload to download at full speed :)
16:59*yorick could get 100 mbit/s up+down, but it costs 60 euros a month extra :(
16:59<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
16:59<TrueBrain>even 1/8th for torrents :p
16:59*KenjiE20 has 700kbps down / 448 kbps up :P
16:59<TrueBrain>I pay 12 euro 50 a month :p
17:00<KenjiE20>hurrah for not being big enough for BT to give a rats
17:00<Eddi|zuHause>frosch123: oh... damn... if only i had known that from the start...
17:02<TrueBrain>I HATE OVERLAYS! (16bit dos stuff)
17:02<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.
17:06-!-frosch123 [] has quit [Remote host closed the connection]
17:06<TrueBrain>night frosch123
17:07-!-Nite_Owl [] has joined #openttd
17:07-!-Azrael- [] has quit [Ping timeout: 480 seconds]
17:07<Nite_Owl>Hello all
17:07<TrueBrain>morning Nite_Owl
17:07<Nite_Owl>Hello TrueBrain
17:08<TrueBrain>am I not included in the all? :(
17:10<Nite_Owl>Yes you are. I always do an 'all' and then respond individually to whomever responds to the 'all'.
17:12<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?
17:13-!-tdev [] has joined #openttd
17:13<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
17:13<TrueBrain>welcome tdev
17:13<Akoz>you have enough trains that you have several depots, each wich one single line
17:13<Akoz>having a waypoint span over those lines and then sending the trains to that waypoint would be imba
17:13<tdev>hi TrueBrain :)
17:14<KenjiE20>also, multitrack avoidance loops
17:15<Eddi|zuHause>separating platforms by direction
17:15<Eddi|zuHause>use platforms 1-3 for direction A
17:15<Eddi|zuHause>use platforms 4-5 for direction B
17:16<Nite_Owl>Akoz: could you not do the same thing by giving the trains specific depot orders
17:16<Eddi|zuHause>use platforms 6-8 for trains that turn around
17:17<Eddi|zuHause>or separating trains by cargo type
17:17<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
17:18<Akoz>and its much more tedious
17:18<Akoz>also with waypoint its easier to expand
17:18<Akoz>add more tracks with depots
17:18<Akoz>without having to re-give orders to all those 200 trains u have going into the same station
17:18<KenjiE20>and would get annoying with trains crossing the junction and/or shared orders
17:19<TrueBrain>Akoz: isn't multispan depots easier?
17:19<Akoz>is that possible?
17:19<Nite_Owl>That is valid as is Eddi's example
17:19<TrueBrain>that wasn't the question ;)
17:19-!-ecke [~ecke@] has quit [Quit: ecke]
17:19<Akoz>I'd go with waypoints instead if I could choose
17:19<Eddi|zuHause>TrueBrain: i was under the impression that internally, waypoints are much closer to depots than to stations
17:20<TrueBrain>Eddi|zuHause: yeah .. something like that I guess
17:20<TrueBrain>I never used WPs, that is why I ask Akoz :)
17:20<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
17:20<Eddi|zuHause>so making waypoints multi-tile would be roughly the same effort as making depots multi-tile
17:21<TrueBrain>Akoz: PF problems are outdated with YAPF :)
17:21<TrueBrain>that would have holded with older PFs, but not with YAPF :)
17:21<Nite_Owl>KenjiE20: what are multitrack avoidance loops? is there an example on the coop site?
17:22<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....
17:23<Akoz>how about simply balancing loads on tracks?
17:23<Nite_Owl>I will buy that
17:23<Akoz>you have 3 tracks going from a to b and you have 3 more going from a through c to b
17:23<TrueBrain>I wish you all a very good night
17:23<Nite_Owl>Thank you all - my question is answered
17:23<Akoz>all trains choose the direct route and it gets clogged.. you want to reroute nonessential trains to the longer route
17:23<Nite_Owl>later TrueBrain
17:24<KenjiE20>nite TrueBrain
17:24<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...
17:24<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...
17:24<Tekky> necessary if waypoints could span multiple tracks.
17:24<KenjiE20>wall of text
17:25<Akoz>What tekky said.. :)
17:26<Nite_Owl>well you can use single station tiles to span multiple tracks and then use the 'via' order
17:27<Akoz>then you can do that for waypoints too.. you might as well remove the waypoints :)
17:27<Tekky>Nite_Owl: Yes, but then I have an unserviced station which gives me a rating penalty from the authorities.
17:27<KenjiE20>and you'd have to remove track
17:27<KenjiE20>screwing with heavy flowing lines
17:28-!-Dred_furst` [] has joined #openttd
17:28<Akoz>and ofc it can only be as big as the station size
17:28<Nite_Owl>understood - I do not worry about ratings that much personally but I do see your point
17:28<Akoz>although I guess that might be the same problem with waypoints
17:29<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
17:29-!-yorick [] has quit [Quit: Poef!]
17:30-!-TheCondor [] has quit [Quit: ( :: NoNameScript 4.1 :: )]
17:30<KenjiE20>not forgetting with stations, if one train has a bad order....
17:32<Akoz>right. stops :p
17:32<KenjiE20>and potentially starts a rivalling pax pickup
17:33<KenjiE20>or whatever
17:35-!-Dred_furst [] has quit [Ping timeout: 480 seconds]
17:35-!-Dred_furst` [] has quit [Read error: Connection reset by peer]
17:36<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.
17:36-!-Dred_furst` [] has joined #openttd
17:39<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
17:40-!-Dred_furst` [] has quit [Read error: Connection reset by peer]
17:44-!-fonsinchen [] has quit [Remote host closed the connection]
17:50-!-Biolunar [] has quit [Quit: gn8]
17:55<Akoz>are there any known bugs with multiplayer passwords in 0.7.1?
18:01-!-orudge` [~orudge@] has quit [Ping timeout: 480 seconds]
18:09-!-KritiK [] has quit [Quit: Leaving]
18:14-!-orudge` [~orudge@] has joined #openttd
18:14-!-mode/#openttd [+o orudge`] by ChanServ
18:18-!-Progman [] has quit [Remote host closed the connection]
18:18-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
18:19<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
18:20<Akoz>then you wouldnt need depots at every junction to avoid trains getting lost
18:23<Nite_Owl>give them 'go to depot' or 'service at depot' orders
18:24<Nite_Owl>they will only go to those depots
18:25-!-TheMask96 [] has joined #openttd
18:28<Akoz>I mean I would like a set of depots they can go to
18:28<Akoz>without having to micro each train by giving specific depot orders
18:29<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
18:29<Akoz>to combat that one has to build depots at every intersection at the main track
18:33<Akoz>do you know what I mean?
18:36<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
18:37-!-KingJ is now known as kingj
18:40-!-oskari89 [oskari89@] has quit [Quit: Utm A½ - Aja 35]
18:40<Akoz>then they wont go to any other depot even if they get to 0 reliability?
18:41<Nite_Owl>they should not but I would not swear to that
18: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
18:42<Akoz>I always have a depot before or after a loading station (or both)
18:43<Akoz>but when having cross-map tracks trains might need 1-2 depot stops per way
18:43<Akoz>then I have to predict myself when the train will need depot stops and make the appropriate orders
18:44<Akoz>and if traffic clogs up a bit trains will end up at really low reliabilities potentially causing jams
18:44<Nite_Owl>you can put in multiple 'service at depot' orders
18:44<Akoz>is there a difference between service at depot, and just go to depot?
18:45<Akoz>I never got that.. reliability is up to max in either case
18:45<Nite_Owl>service at depot = stop if needed go to depot = always stop
18:45<Akoz>and what decides if it is needed?
18:45<Nite_Owl>depends on your servicing settings
18:46<Akoz>with default?
18:46<Nite_Owl>180 days ?
18:47<Akoz>for example
18:47-!-stuffcorpse [~rick@] has quit [Remote host closed the connection]
18:47-!-stuffcorpse [~rick@] has joined #openttd
18:48<Nite_Owl>so a train will travel for 180 days before it needs to stop at a depot - or close to 180 days
18:49<Nite_Owl>if you have a very long route you would plan out your depots accordingly
18:50<Nite_Owl>I play with breakdowns off but servicing on and my servicing interval set to 365 days
18:51<Akoz>well if you play with breakdowns off it doesnt really matter
18:51<Nite_Owl>so once a year my trains visit a depot
18:51<Xaroth>I disable servicing when breakdowns are off :P
18:51<Akoz>my point is
18:51<Akoz>if you have a track that takes 500 days to complete
18:51<Akoz>you probably need more depots
18:52<Nite_Owl>I still like them to visit the depots for sake of the R word
18:52<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
18:52<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
18:52<Akoz>then it'll take off and go to another random depot that will cause it to get lost
18:53<Akoz>or if you have "infinite" time to depot it will continue until its 0% trying to get to the designated depot
18:53<Akoz>further more these designated depots are a nightmare if you have to give ALL your trains extra orders to go to those depots
18:53<Nite_Owl>not if you use depot orders - it will never hunt out a random depot
18:54<Akoz>so when travel time changes you need to re-do the orders for the trains
18:55<Nite_Owl>Why? If it works for slower trains then it will work for faster ones too.
18:55-!-Chruker [] has quit []
18:55<Akoz>if it changes positivly yes
18:55-!-Coco-Banana-Man [] has quit [Quit: Raubgut ist vom Umtausch ausgeschlossen!]
18:55<Akoz>but if more traffic causes it to take longer time to travel you have a problem
18:56<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
18:56<Nite_Owl>then you may have to build in additional yards for the train(s) to stop in
18:57<Akoz>but the biggest hinder for your approach is to set up the trains in the first place
18:57<Akoz>having to add say 2 half way depots per way for each train
18:57<Akoz>changing amount of orders from 2 to 6 for each train you make
18:57<Akoz>thats a lot of extra work
18:57<Akoz>easaier and safer to add depots at all exits
18:58<Nite_Owl>not if you are sharing orders and have a good idea of when your trains will need service
18:58<Akoz>Im always sharing orders
18:58<Nite_Owl>then you only have to change the orders for one train
18:58<Akoz>uhm. no
18:59<Akoz>for each loading station you have a different set of orders
18:59-!-Azrael- [] has joined #openttd
18:59<Akoz>with typically 200 trains you probably have at least 50 loading stations
18:59<Nite_Owl>yes - that is correct
18:59<Akoz>and 50 sets of orders
18:59<Nite_Owl>do you group your trains
18:59<Akoz>not usually
19:00<Akoz>never found a purpose for it
19:00<Nite_Owl>it becomes much easier to do if you group them
19:00<Akoz>how so
19:00<@Belugas>they do smoke togueter
19:00<@Belugas>nice and fun to see
19:01<Nite_Owl>each group has only trains in it that share orders
19:01<Akoz>as in identical orders?
19:01-!-Dred_furst [] has joined #openttd
19:01<Akoz>uhm. then what is the point of grouping? when you change 1 order you change all
19:02<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
19:03<@Belugas>group them for any propose you want. it is a way to organize your fleet
19:03<@Belugas>i usually group my trains by usage, i.e cargo
19:03<@Belugas>or lines
19:03<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
19:04<Akoz>acctually I usually just click the train already in the station
19:04<Akoz>if theres an order change
19:04<Akoz>theres always one train loading
19:05<Nite_Owl>yes but then you have to go around to each station
19:05<Nite_Owl>instead of to one open window
19:05<Akoz>when do you want to change the order of all trains?
19:06<Nite_Owl>all trains in a group?
19:06<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
19:06<Nite_Owl>that is a good example
19:06-!-Tekky_ [] has joined #openttd
19:06<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
19:06<Nite_Owl>also if you need to add a depot
19:07-!-Azrael- [] has quit [Ping timeout: 480 seconds]
19:08<Nite_Owl>there are also several other options in drop down menus at the bottom of each group's window
19:09<Nite_Owl>those option will only affect that group
19:09<Nite_Owl>and not the rest of your trains
19:10<Nite_Owl>again - all of this is up to your own playing style - use them if you like
19:12<Nite_Owl>or do not use them if you do not like to
19:14<Nite_Owl>I need to feed - later all
19:14-!-Netsplit <-> quits: Strid__, PhoenixII, +Patrick`, Markk, +glx, TheMask96, _ln, octo, Default__, valhallasw, (+70 more, use /NETSPLIT to show all of them)
19:14-!-Netsplit over, joins: tdev, planetmaker, Fuco, +glx, wolfy, KenjiE20, +tokai, _ln, Eddi|zuHause, TrueBrain (+17 more)
19:15<Nite_Owl>A net split just I am leaving - how odd
19:15-!-Netsplit over, joins: +michi_cc, jonty-comp, Muddy, DephNet[Paul], Mucht, [com]buster, Zahl, MizardX, TinoDidriksen, welshdragon (+9 more)
19:16-!-Netsplit over, joins: Tekky_, OwenS, HerzogDeXtEr1, George3, KUDr, PhoenixII, elmex, goodger, kingj, valhallasw (+13 more)
19:16-!-Netsplit over, joins: TheMask96, Wolle, helb, LadyHawk, Akoz, dfox, Exl, Zr40_, Westie, edeca
19:16<Akoz>and.. we're back
19:17-!-Nite_Owl [] has quit [Quit: Read You Soon]
19:25-!-Aali_ [] has joined #openttd
19:26-!-mode/#openttd [+v orudge`] by ChanServ
19:26-!-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
19:27-!-Aali [] has quit [Ping timeout: 480 seconds]
19:29-!-mode/#openttd [+v DorpsGek] by ChanServ
19:31-!-Exl [] has quit [Quit: Bitches.]
19:33-!-Eddi|zuHause [] has quit []
19:33-!-Eddi|zuHause [] has joined #openttd
19:33-!-Tekky [] has joined #openttd
19:39-!-Tekky_ [] has quit [Ping timeout: 480 seconds]
19:44-!-Dred_furst [] has quit [Quit: Leaving]
19:44-!-tdev [] has quit [Quit: free open source vehicle simulator:]
20:06-!-Wolle [] has quit [Ping timeout: 480 seconds]
20:08-!-KenjiE20 [~KenjiE20@] has quit [Quit: WeeChat 0.3.0-rc2]
20:32-!-Tekky_ [] has joined #openttd
20:37-!-Tekky [] has quit [Ping timeout: 480 seconds]
20:38-!-Tekky_ is now known as Tekky
20:42-!-Akoz [] has quit [Ping timeout: 480 seconds]
20:49-!-OwenS [] has quit [Remote host closed the connection]
21:09-!-Aali_ is now known as Aali
21:19-!-Zahl [] has quit [Quit: *schiel*]
21:49-!-JFBelugas [] has quit [Ping timeout: 480 seconds]
21:53-!-Tekky [] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.1/20090715094852]]
22:05-!-PeterT [] has joined #openttd
22:08-!-PeterT [] has quit []
22:17-!-nfc [] has quit [Ping timeout: 480 seconds]
22:19-!-nfc [] has joined #openttd
22:25-!-keoz [] has quit [Quit: Leaving]
22:26-!-Pygma [~quassel@] has quit [Read error: Connection reset by peer]
22:34-!-welshdragon [~welshdrag@] has left #openttd []
22:38-!-stuffcorpse [~rick@] has quit [Quit: leaving]
22:39-!-stuffcorpse [~rick@] has joined #openttd
23:03-!-glx [glx@2a01:e35:2f59:c7c0:2198:8523:b023:2c79] has quit [Quit: bye]
23:08-!-TinoDidriksen [] has quit [Ping timeout: 480 seconds]
23:12-!-TinoDidriksen [] has joined #openttd
23:14-!-Nite_Owl [] has joined #openttd
23:14<Nite_Owl>Hello all
23:38-!-TinoDidriksen [] has quit [Ping timeout: 480 seconds]
23:42-!-TinoDidriksen [] has joined #openttd
23:44-!-Fuco [] has quit [Ping timeout: 480 seconds]
---Logclosed Mon Jul 20 00:00:44 2009