Back to Home / #openttd / 2008 / 08 / Prev Day | Next Day
#openttd IRC Logs for 2008-08-13

---Logopened Wed Aug 13 00:00:11 2008
---Daychanged Wed Aug 13 2008
00:00-!-Gekz_ [] has quit [Quit: leaving]
00:38-!-Rexxars [~rexxars@] has quit [Quit: edgepro: A man who smiles when things go wrong knows who to blame.]
00:39-!-Vikthor [] has joined #openttd
00:52-!-Vikthor [] has quit [Quit: Leaving.]
00:54-!-Reemo [] has quit [Quit: - das Wiki rund um's Thema Lager und Logistik]
01:02-!-dlunch [~dlunch@] has quit [Remote host closed the connection]
01:02-!-dlunch [~dlunch@] has joined #openttd
01:12<CIA-5>OpenTTD: rubidium * r14062 /trunk/src/ai/trolly/trolly.cpp: -Fix [FS#2226]: division by 0 in newai.
01:37-!-Suisse[Dodo]12ILvVgnnu [] has joined #openttd
01:41-!-Suisse [] has quit [Ping timeout: 480 seconds]
01:56-!-Sir-Bob [] has joined #openttd
01:56-!-Zorni [] has joined #openttd
02:01<Frostregen> ;)
02:04-!-Zorn [] has quit [Ping timeout: 480 seconds]
02:05<CIA-5>OpenTTD: rubidium * r14063 /trunk/src/ (19 files in 3 dirs): -Codechange: replace some "magic" constants with enumified constants.
02:07-!-Ridayah_ [] has joined #openttd
02:08-!-Ridayah [] has quit [Read error: Connection reset by peer]
02:13<@peter1138>Hehe, copying the map to do multithreaded drawing... how silly :D
02:13<@Rubidium>yeah, copying the map's not enough
02:19-!-dlunch [~dlunch@] has quit [Remote host closed the connection]
02:20-!-mikl [] has joined #openttd
02:22<CIA-5>OpenTTD: rubidium * r14064 /trunk/src/ (8 files): -Fix [FS#1752]: check for the length of strings (in bytes) in the command. Checking for the length in pixels is impossible because that differs per client.
02:45-!-Suisse[Dodo]12ILvVgnnu is now known as Suisse
02:48-!-flow0ver [] has joined #openttd
02:51-!-ob0t_ [] has joined #openttd
02:51-!-Frostregen [] has quit [Quit: und weg]
02:52-!-ob0t [] has quit [Read error: Connection reset by peer]
02:52-!-Eddi|zuHause [] has quit [Remote host closed the connection]
02:52-!-Eddi|zuHause [] has joined #openttd
02:54-!-flowOver [] has quit [Ping timeout: 480 seconds]
03:04-!-mikl [] has quit [Quit: Leaving...]
03:07-!-Rexxars [~rexxars@] has joined #openttd
03:15<@peter1138>Rubidium, except that 31 bytes is not very much :(
03:15<@peter1138>Not enough at all.
03:18<@peter1138>We should change that to characters if possible.
03:24-!-flowOver [] has joined #openttd
03:24-!-SquireJames [SquireJame@] has quit []
03:27<De_Ghost>soooooooo peter1138
03:27<De_Ghost>when is signal in tunnel comming ? :D
03:28<De_Ghost>you made that esk yet?
03:30-!-flow0ver [] has quit [Ping timeout: 480 seconds]
03:33-!-thingwath [] has joined #openttd
03:38<@peter1138>I'm not doing signals in tunnels.
03:39<Fennec>don't blameya
03:41-!-Brianetta [] has joined #openttd
03:42<@Rubidium>peter1138: I haven't changed any limits whatsoever
03:43<@peter1138>I noticed.
03:43<@peter1138>My point still stands :)
03:45-!-TinoM [] has joined #openttd
03:47-!-TinoM [] has quit []
03:57*Rubidium is amazed by the "security" world
03:59<@Rubidium>making a fuzz about something that's hardly remotely trigerrable and not mentioning the thing that's easily remotely triggerable
04:02<ln>hmm, someone has stolen tons of rails in northern finland.
04:02<ln>from a track abandoned long ago.
04:02<Fennec>metal is $$$ these days.
04:03<@peter1138>De_Ghost, nearly complete ;)
04:03<@peter1138>What the hell happened to Classic FM's ident?
04:04<ln>the interesting thing is that keeping the track and not demolishing it is part of the peace treaty between Soviet Union and Finland.
04:07-!-Brianetta [] has quit [Quit: Tschüß]
04:09<De_Ghost>what wood did u use/.
04:12-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
04:12<@peter1138>ln, so Russia will start another war? Heh
04:14<ln>that's what i'm expecting
04:15<thingwath>is that treaty still effective, if there is no Soviet Union for more than 15 years? :)
04:16<Noldo>thingwath: that is an interesting question
04:16<ln>it shouldn't matter that the track has been unused since 40's, and has been partially demolished on the Russian side.
04:16<Noldo>ln: do you know if it's the same treaty that limited number of fighter jets?
04:16<thingwath>ln: so not Russia should invade Finland, but Finland should invade Russia :)
04:17<ln>thingwath: that has been tried, with temporary success.
04:17<thingwath>I mean after 40's :)
04:17<ln>Noldo: dunno, but i would assume there is only one treaty...
04:18<Noldo>ln: anyway the fighter jet limit was broken when buing hornets
04:20<Noldo>ln: olso it seems we were forbidden from buying military material from germany
04:23<ln>which germany?
04:25<Noldo>haha, now that is an interesting question
04:33<Noldo>it doesn't say, just "Finland shall not buy or manufacture military material of german origin or model"
04:34-!-peter1138 [] has quit [Ping timeout: 480 seconds]
04:36-!-peter1138 [] has joined #openttd
04:37-!-mode/#openttd [+o peter1138] by ChanServ
04:37-!-mikl [] has joined #openttd
04:51-!-CelestarT42p [] has joined #openttd
04:52-!-tokai|madspace [] has quit [Ping timeout: 480 seconds]
04:52-!-fonso [] has joined #openttd
04:52<Ailure>neat newGRF presets
04:52<CelestarT42p>peter1138: got a minute?
04:54-!-tokai|madspace [] has joined #openttd
05:00-!-mucht_work [~Martin@] has joined #openttd
05:01-!-mucht_work [~Martin@] has quit [Remote host closed the connection]
05:06-!-mucht_work [~Martin@] has joined #openttd
05:17-!-Eddi|zuHause [] has quit [Remote host closed the connection]
05:18-!-Eddi|zuHause [] has joined #openttd
05:22-!-Wolf01 [] has joined #openttd
05:25-!-Farden [] has joined #openttd
05:37-!-Bjarni [] has joined #openttd
05:37-!-mode/#openttd [+o Bjarni] by ChanServ
05:38-!-Yorick [] has joined #openttd
05:39<@peter1138>CelestarT42p, sup?
05:43<CelestarT42p>peter1138: sorry, galadriel apparently crashed
05:44<CelestarT42p>peter1138: so I have some local changes, how can I propagate them, and do you have some place to pull changes from?
05:46<CelestarT42p>well, galadriel didn't crash but the ssh daemon is down :S
05:46<Yorick>Kloopy: are you there?
05:49<CelestarT42p>peter1138: cuz I'm behind a NAT
05:51-!-divo [] has joined #openttd
05:51<Kloopy>Hi Yorick, yeah.
05:51<Kloopy>I have the file!
05:51<Yorick>k :)
05:51<Kloopy>Give me a mo.
05:51<Yorick> :)
05:51<@peter1138>Oh, right...
05:52-!-divo [] has quit []
05:52<@peter1138>Well you can hg serve your local changes ;)
05:52<@peter1138>My copy isn't synced with yours thouhg.
05:52-!-divo [] has joined #openttd
05:52<CelestarT42p>peter1138: behind the NAT?
05:52<CelestarT42p>I got another server, but there's no copy, so I need to start with summin
05:52<@peter1138>Well, mine is behind NAT ;)
05:53<@peter1138>Hang on, I've got another copy.
05:53<CelestarT42p>peter1138: cool
05:53<@peter1138>Not updated since Friday though.
05:54<CelestarT42p>perfect (=
05:55<Yorick>Kloopy: are you sure mass depot service, autoreplace, autorenew, or newgrfs are not used?
05:55<@peter1138>Is mass depot service unsafe too?
05:55<Kloopy>I asked everyone if they were using autoreplace and they all promised they were not.
05:55<Kloopy>It's only 3 years into the game so there is no autorenew happening.
05:55<Kloopy>And 100% sure there are no grfs used.
05:56<CelestarT42p>Kloopy: what are we talking about? (=
05:56<Yorick>he's got reproducable desyncs on vanilla openttd
05:56<Kloopy>CelestarT42p: a game that desynced based on a vanilla nightly over the weekend.
05:56<CelestarT42p>not good
05:58-!-dvo [] has joined #openttd
05:58-!-divo [] has quit [Read error: Connection reset by peer]
06:00<dih>i only run vanilla nightlies - and saw quite a few desincs at some point too - just cannot remember when it was :-P
06:01<@peter1138>Yorick, but mass depot service does not mean autoreplace...
06:01<Yorick>I don't know mass depot autoreplace
06:02<@peter1138>That's what the report said.
06:03-!-fmauNekAway is now known as fmauNeko
06:03<CelestarT42p>erm peter1138 .. I have a new repo on
06:04<CelestarT42p>peter1138: is that the latest of your stuff?
06:07<Yorick>Kloopy: when does the desync happen?
06:08<Kloopy>It was about a minute after unpausing. I can't say for 100% sure.
06:08<@peter1138>CelestarT42p, no, my home PC is down.
06:08<dih>Rubidium: i noticed another thing with the console gui this time
06:09<dih>there are no line breaks
06:09<dih>i.e. a chat message that is a wee bit too long cannot be read in the console gui
06:09<dih>at least not fully
06:10<CelestarT42p>peter1138: k np then
06:10<Yorick>Kloopy: I can't reproduce your desync
06:10<@peter1138>In my version non-destinations does not work, but I don't know if that was fixed.
06:10<Kloopy>Ah man.. that sucks... I'll try here and see if I can.
06:12<@peter1138>Can anyone reach on port 25?
06:13<CelestarT42p>peter1138: nmap sais filtered
06:13<CelestarT42p>peter1138: can't telnet into it
06:15-!-Prof_Frink [] has joined #openttd
06:15<CelestarT42p>peter1138: so our real desync test will have to wait till the probs in trunk are fixed (if there are some)
06:15<CelestarT42p>or not?
06:16<@peter1138>Possibly. I don't know if frosch's autoreplace patch has had much testing yet.
06:16<@Rubidium>auto* needs to be fixed for sure
06:16<CelestarT42p>Rubidium: what other elements are in "*" except replace?
06:17<CelestarT42p>peter1138: he did a rewrite already?
06:17<@Rubidium>CelestarT42p: renew
06:17<@peter1138>autobjarni :D
06:17<@peter1138>All bjarni's stuff breaks ;)
06:17<Yorick>Rubidum: frosch123 is assined to it :)
06:17<@peter1138>autoreplace, osx port...
06:17<CelestarT42p>what's the problem with autorenew?
06:17<@peter1138>CelestarT42p, it's the code path as autoreplace.
06:17<CelestarT42p>I mean apart from the fact that is sometimes fails for no reason :P
06:18<CelestarT42p>peter1138: I see. Maybe we should conduct the test then without any autoreplace or summin
06:18<Yorick>I think the new autoreplace should be vehicle-specific
06:18-!-Brianetta [] has joined #openttd
06:18<@Rubidium>CelestarT42p: that's hardly controllable
06:18<@peter1138>You're entitled to think what you like.
06:19<@peter1138>Morning Brianetta.
06:19<Brianetta>Hello (:
06:19<CelestarT42p>hey Brianetta
06:19<dih>hello Brianetta
06:19<Yorick>also the vehicle callback is tested without DC_EXEC too
06:19<Brianetta>Just thought I'd pop on, between crises
06:19<Yorick>hello Brianetta
06:19<CelestarT42p>peter1138: hg pull should work for a merge?
06:20<CelestarT42p>er .. 404 :P
06:20<@peter1138>I keep a local trunk hg repo. Means I can clone it quickly for testing new things as often as I like. It's almost quicker than cp -a'ing a trunk svn checkout.
06:21<CelestarT42p>66 files updated, 35 files merged, 0 files removed, 3 files unresolved
06:21<CelestarT42p>I *think* I fucked this up
06:21-!-Eddi|zuHause [] has quit [Remote host closed the connection]
06:21<@peter1138>Nope, just 3 files to manually merge.
06:21-!-Eddi|zuHause [] has joined #openttd
06:21<CelestarT42p>that many changes? :o
06:21<Eddi|zuHause>what's wrong today?
06:21<Brianetta>Does Mercurial offer any advantages over SVN for somebody like me, who just wants up to date source to compile, and occasionally wants to apply a debug patch from a developer?
06:21<@peter1138>Language updates change a lot of files ;)
06:22<Eddi|zuHause>it's the 3rd time i get disconnected from oftc today
06:22<@peter1138>Probably not, Brianetta.
06:22<Brianetta>Well, since I have SVN all set up and working, I'll stick with it.
06:23<Eddi|zuHause>hg is useful if you do local development, like a patch
06:23<Brianetta>That's rare
06:23<Brianetta>I'm more of an apply and test kind of guy
06:23<@peter1138>An hg clone contains everything, including history. So it's useful for development, but not really just testing a patch.
06:23<Eddi|zuHause>then hg is not the right tool ;)
06:24<CelestarT42p>hg view is neat :P
06:24<Brianetta>I'm impressed that so many revision control systems work together
06:24<Yorick>Brianetta: hg has a svn convert tool
06:24<@peter1138>It is next, yes.
06:24<Eddi|zuHause>hg view is fun when you have multiple parallel development lines ;)
06:24<@peter1138>Eddi|zuHause, which we do :)
06:25<CelestarT42p>Eddi|zuHause: yeah
06:25<Brianetta>So hg would be ideal if you were maintaining an integrated nightly
06:25<CelestarT42p>peter1138: although the "some kind of merge" did mess it up :P
06:25-!-Dred_furst [] has joined #openttd
06:25<Eddi|zuHause>yes, for example
06:25<@peter1138>Yes, that did.
06:26<Kloopy>Yorick: I can't replicate the desync either. :( Perhaps it was something someone was doing whilst we were playing. But I can't find it. :(
06:26-!-stillunknown [] has joined #openttd
06:26<@peter1138>But that was because the original hg repo was replaced with a complete one, so not actually my fault.
06:26<Brianetta>Kloopy: Did you have trams?
06:26<Kloopy>No, no GRFs.
06:26<Yorick>Brianetta: no grfs were used
06:26<Brianetta>This weekend, I plan to run a local server at my home, and do some intensive testing.
06:27<Brianetta>See if I can't get it to desync.
06:27<CelestarT42p>peter1138: yeah :P
06:27<Brianetta>My Standard Server is desyncing all players at the moment
06:27<Brianetta>and still is, even though I saved, exited and reloaded the dedicated server
06:27<Brianetta>so it wasn't a one-off cause
06:27<Yorick>but it's using grfs
06:27<Dred_furst>Mine is too,
06:27<Brianetta>It is. It still shouldn't desync.
06:27<Yorick>and afaik desync-debug isn't in 0.6.2
06:27<@Rubidium>without it being reproducable for us... we can't do a thing about it
06:28<Kloopy>Of course Rubidium.
06:28<Brianetta>Rubidium: I'm aware. That's why I'm going to try some testing this weekend.
06:28<Dred_furst>people are reporting monthly desyncs on mine
06:28<Dred_furst>and the autosave is monthly
06:28<Kloopy>Yorick: We did have another map that we were getting desyncs on, but it wasn't everyone it was just one or two people so we assumed it was a problem with their machines somehow.
06:28<@Rubidium>0.6.x shouldn't be influenced by the autoreplace crapness of trunk
06:29<Brianetta>0.6.2 is not desyncing because of any player action, gui, command or otherwise.
06:29<Yorick>I think autoreplace should be removed from trunk completely, or disabled...
06:30<Brianetta>It's desyncing when I connect as the only player, and just watch the trains.
06:30<Brianetta>Yorick: It's fine in 0.6.2; removal isn't necessary
06:30<Yorick>Brianetta: _trunk_ ;)
06:30<@Rubidium>Yorick: and what would be the reason to do so?
06:31<Yorick>the crapness?
06:31<@Rubidium>then don't use trunk
06:31<@peter1138>I haven't seen Yorick's patch to fix it.
06:31<@Rubidium>people are working on fixing it
06:31<CelestarT42p>so 0.6.2 is desyncing as well?
06:32<@Rubidium>well, there never was a version that didn't desync
06:32<CelestarT42p>Dred_furst: why don't you set autosave on quarterly and see what happens=?
06:32<Dred_furst>I always notice my games stall a bit when it autosaves
06:32<Yorick>could be news messages too
06:32<Dred_furst>(in SP)
06:33<CelestarT42p>Dred_furst: well, sure
06:33<@Rubidium>news messages don't change the game state
06:33<CelestarT42p>Dred_furst: unless you have > 1 CPUs
06:33<Dred_furst>if the server stalls a bit and the client's aren't auto saving the server will desync
06:33<Yorick>wasn't there a bug with 0.6.1-RC1 and desyncs and news messages?
06:33<Dred_furst>how does the no. of CPU's change how it reads the map?
06:33<@peter1138>Dred_furst: Wrong.
06:33<Yorick>Dred_furst: wrong
06:33<@Rubidium>Yorick: no
06:33<Yorick>something with PACKET_SERVER_FRAME?
06:34<@peter1138>The server can never desync. It is authoritative.
06:34<Dred_furst>that was my stab in the dark anyway
06:34<Dred_furst>ok it would cause the clients to desync
06:34<Yorick>Dred_furst: still wrong
06:34<@peter1138>It wouldn't, anyway.
06:34<Dred_furst>unless the clients stall a bit too
06:34<Yorick>Dred_furst: the clients wait for the server
06:34<@peter1138>If the server stalls too long, then the clients might disconnect, but that is not a desync.
06:34<Dred_furst>you guys know the code base much better than I do
06:35<Dred_furst>so what would be the reason for a desync?
06:35<CelestarT42p>Dred_furst: different PRNG results
06:35<CelestarT42p>Dred_furst: that's the ONLY reason
06:35<Yorick>Dred_furst: you tell us :)
06:35<Dred_furst>What on earth are different PRNG results
06:35<Yorick>CelestarT42p: no, different amount of calls to PRNG
06:35<CelestarT42p>Yorick: same difference
06:35<@peter1138>Pseudo random number generator.
06:36<CelestarT42p>Dred_furst: what peter1138 said
06:36<Yorick>Dred_furst: what CelestarT42p said
06:36<Dred_furst>Ok, so I guess the PRNG is used in identifiying network packets?
06:36<CelestarT42p>Yorick: but even with the same amount of calls the results may be different
06:36<CelestarT42p>Dred_furst: no, it used in the game engine
06:36<Yorick>CelestarT42p: would they?
06:37<@peter1138>CelestarT42p, then that's a faulty PRNG.
06:37<Dred_furst>Why don't you get the server to tell the clients what random number to use?
06:37<CelestarT42p>Yorick: peter1138 buffer overflow into the seed can be a reason (I think we had that once, didn't we?)
06:37<CelestarT42p>Dred_furst: bandwidth
06:37<Dred_furst>how often is it called?
06:37<CelestarT42p>Dred_furst: enable desync debug and you'll see
06:37<@Rubidium>enough to make a 100 MB log a minute
06:37<Dred_furst>Right ok
06:37<Yorick>CelestarT42p: then it would be far more common
06:38<Dred_furst>then the second question is why would the client call the PRNG more times than the server?
06:38<Dred_furst>or vice versa
06:38<Yorick>Dred_furst: that is the bug
06:38<@peter1138>Due to different state.
06:38<CelestarT42p>or different codebases (theoretically)
06:38<Dred_furst>then you need a system to roll back a state and catch up with the server
06:38<Yorick>if (!_network_server) Random();
06:39<@peter1138>The most usual cause these days is cached data not matching between server and clients.
06:39<@Rubidium>Dred_furst: and how far do you need to roll back?
06:39<Dred_furst>I guess you would have to provide hashes
06:39<CelestarT42p>Dred_furst: we have that. Just re-connect :P
06:39<Dred_furst>Make the game sort itself out, rather than reconnect
06:39<@peter1138>Gah, why do PC cases suck so bad?
06:39<CelestarT42p>Dred_furst: auto-reconnect on desync?
06:40<Dred_furst>per say
06:40<Yorick>Dred_furst: sorting itself out = reconnect
06:40<@peter1138>The solution is to fix all desyncs, not work around them.
06:40<CelestarT42p>peter1138: dunno. Made in Taiwan probably :P
06:40<@peter1138>Ah, probably.
06:40<CelestarT42p>peter1138: or change the architecture and have a server/client system instead of a P2P system
06:40<@peter1138>The base simple case I've seen recently is microATX :(
06:40<Yorick>Dred_furst: if it desyncs, it is quite likely the map differs too, and you can only solve that by getting a new copy of the map
06:40<Brianetta>Desyncs could be debugged, by having the server and client exchange a token every time a random number is generated. If they don't exchange the same token in the same frame, then log which function called the RNG. High bandwidth use, but that's fine on a LAN test environment.
06:41<@peter1138>What is peer-to-peer?
06:41<Yorick>client to client
06:41<CelestarT42p>peter1138: basically the openttd networking is peer-to-peer (logically, not networkically)
06:41<@Rubidium>Brianetta: what's much quicker and more efficient is dumping the random calls to a file and diff that
06:41<@peter1138>No it's not.
06:41<Dred_furst>I guess if you encounter a desync, force the PRNG to reset with a new seed
06:41<CelestarT42p>every client has a full state
06:42<Brianetta>Rubidium: Admittedly, true
06:42<Dred_furst>and the server can broadcast this to the clients
06:42<CelestarT42p>Dred_furst: and what seed would that be?
06:42<Yorick>Dred_furst: the map is still likely to be different then
06:42<@Rubidium>Brianetta: and you can force to check sync every frame
06:42-!-Roujin [] has joined #openttd
06:42<Dred_furst>one randomly generated by the OS
06:42<Yorick>Dred_furst: for all clients?
06:43<CelestarT42p>Dred_furst: and how do you make sure that we have identical maps on all the clients?
06:43<Dred_furst>generate the seed on the server, distrobute to the clients
06:43<@peter1138>How would that help? The game state is already wrong.
06:43<Dred_furst>ok, How many bytes per map tile is there?
06:43<CelestarT42p>Dred_furst: when the game desyncs, the state HAS diverged already
06:43<@Rubidium>Dred_furst: once you encounter a desync there is a difference in the game state between the server and client. Resyncing the seed doesn't solve the problem, it only makes them grow further apart each tick
06:43<CelestarT42p>Dred_furst: one and a little bit :P
06:43<Yorick>Dred_furst: landscape_map.h
06:43<Yorick>Dred_furst: landscape_map.html
06:43<Dred_furst>ok let me grab the code
06:43<CelestarT42p>Dred_furst: you don't have to upload the map only
06:43<@Rubidium>Dred_furst: 10-ish per tile
06:43<CelestarT42p>Dred_furst: but the entire savegame
06:44<CelestarT42p>er .. 10 and a little bit :P
06:44<@Rubidium>CelestarT42p: where does the little bit come from?
06:44<Brianetta>Rubidium: If you want me to do this this weekend, send me details. I'll use a clone of my server setup.
06:44<Dred_furst>You could generate a diff between the two, but then one of the machines needs a copy of the other's game
06:44<CelestarT42p>Rubidium: sorry, mixed up bits and bytes just now (=
06:44<CelestarT42p>Dred_furst: yes. that's called connecting. Client loads current gamestate from server :P
06:44<Yorick>Dred_furst: around 72 bits
06:45<@peter1138>There is more to the game state than the map, heh...
06:45<Eddi|zuHause>we should really transfer the savegame 30 times per second ;)
06:45<Dred_furst>I am never going that far
06:45<@peter1138>Bah, I want front panel audio and USB but not firewire...
06:45<CelestarT42p>Eddi|zuHause: how about a diff of the savegame (=
06:45<Eddi|zuHause>oh, much better :)
06:45<Dred_furst>CelestarT42p, one problem
06:45<Dred_furst>you cannot create the diff easily
06:45<CelestarT42p>memcpy :P
06:45<CelestarT42p>and write memdiff :P
06:45<Dred_furst>mainly as the two machines have different states
06:46<@peter1138>Hehe, there was one guy on here who thought we used the server's ability to draw to draw the client views...
06:46<@Rubidium>Brianetta: ./configure --enable-desync-debug=2 for the server and client, then make, ./openttd > logfile and then diff both logfiles after the desync
06:46<Yorick>peter1138: rdp :)
06:46<@Rubidium>after that you go backtracking the issue, usually by adding more output using printfs
06:46<CelestarT42p>Eddi|zuHause: We could also only send the things which actually change the gamestate in an unpredictable way like the commands (=
06:47<CelestarT42p>Eddi|zuHause: er wait, that's what we do :P
06:47<Yorick>Brianetta: you need a reproducable desync first
06:47-!-Progman [] has joined #openttd
06:48*peter1138 still wonders about saving all cached results from NewGRF instead of recalculating them.
06:48<@peter1138>(That, or forcing recalculation for all)
06:48<CelestarT42p>Step 5
06:48<CelestarT42p>Desync found, and likely a whole day further.
06:48<CelestarT42p>a day?
06:48*Yorick knows nothing about desync
06:48<CelestarT42p>you guys been lucky :P
06:49<CelestarT42p>Yorick: well if you read, you know what a desync is now :P
06:49<Yorick>I did already
06:50<CelestarT42p>Rubidium: we add output using cout :P
06:50-!-Eddi|zuHause [] has quit [Remote host closed the connection]
06:51-!-Eddi|zuHause [] has joined #openttd
06:51<CelestarT42p>or cerr rather :P
06:54<@peter1138>That was the old one.
06:54<CelestarT42p>peter1138: shall we remove all this from the wiki?
06:54<@Rubidium>old-old-old-old-old one
06:55<CelestarT42p>heh .. how :P
06:55<@peter1138>I can do it.
06:55<Dred_furst>how much bandwidth does the game require currently to run effectively with 10 people
06:55<CelestarT42p>I don't have a my login here
06:55<CelestarT42p>Dred_furst: about 2Kb/(client sec)
06:56<CelestarT42p>Dred_furst: and it's basically flat-rate
06:56<Dred_furst>and I am right in thinking the game uses a decentralized system with the server being authoritive?
06:56<CelestarT42p>Dred_furst: yes. Each client has the full game state
06:56<Dred_furst>so are some of the client's sending events to each other?
06:56<CelestarT42p>er nope
06:57<Dred_furst>so it isn't decentralized at all
06:57<Yorick>they send commands to the server
06:57<Dred_furst>its client/server
06:57<CelestarT42p>otherwise you'll open a can-of-worms with NAT
06:57<Yorick>which relays them to every other client
06:57<CelestarT42p>Dred_furst: the only thing the client sends are Commands
06:57<Dred_furst>Ok right just wanted to make sure that was correct
06:57<CelestarT42p>server checks them, if it authorizes them, puts them onto all othe clients
06:57<CelestarT42p>(at the same frame)
06:58-!-Tekky [] has joined #openttd
06:58<Dred_furst>and another guess of why things desync is packet loss?
06:58<CelestarT42p>heyo Tekky
06:58<Tekky>hi everyone :)
06:58<Dred_furst>or is it designed to cope with packet loss
06:58<CelestarT42p>Dred_furst: this is TCP (=
06:58<@Rubidium>Dred_furst: TCP has NO packetloss
06:58<CelestarT42p>NOT udp
06:59<CelestarT42p>that's why we're using it
06:59-!-lobster_MB [~michielbr@] has joined #openttd
06:59<@Rubidium>it only has connection loss, which is a completely different error
06:59<CelestarT42p>Rubidium: is there a maximum retransmission value?
07:00<@Rubidium>I reckon there is in TCP
07:00<CelestarT42p>or does TCP just keep trying until it drops the connection
07:00*CelestarT42p guess if you hit the maximum retransmission value, you might have another problem :P
07:00<@Rubidium>if you hit that maximum the connection will be dropped
07:00<Dred_furst>so if TCP needs a packet re-transmitted and it keeps trying and the next frame hits, desync
07:01<@Rubidium>TCP passes the data to the client in the same way it was send by the server
07:01<Yorick>it also guarantees packet order
07:01<Dred_furst>well if the client hasn't got the packet about the next frame yet and the server hits the next frame, you are out of sync
07:01<@Rubidium>whatever happens in between (retransmissions and such) aren't of any concern to the client
07:02<CelestarT42p>the client is only a bit after the server then
07:02<@Rubidium>Dred_furst: no, you are "lagging", not out of sync
07:02<Kloopy>TCP guarantees that packets arrive in the order they are sent, Dred_furst.
07:02<Dred_furst>what I am saying is does the client hop forward to catch up with the server
07:02<@Rubidium>out of sync means: both games at the same tick and the game state differs
07:02<@Rubidium>lagging means: server is a tick (or more) in front of the client
07:02<CelestarT42p>Dred_furst: it can't skip frames
07:03<Yorick>Dred_furst: it just fast-forwards or keeps at it's lagging speed and eventually disconnects
07:03<CelestarT42p>Rubidium: isn't the server always a bit ahead of the clients?
07:03<Dred_furst>so really you need to go through the network system and make sure it is all correct
07:03<Dred_furst>and looking where the function calls are
07:03<Yorick>Dred_furst: fortunatly we've got desync_debug
07:04<@Rubidium>CelestarT42p: not necesarily; the server might be slower than the client in which case ping+game tick takes shorter on the client than game tick takes on the server
07:04<CelestarT42p>Rubidium: yeah
07:04<@peter1138>We don't need to, because the network system works fine.
07:04<Dred_furst>then isn't that a problem
07:04<Dred_furst>it obviously doesn't work fine, people still desync
07:05<@peter1138>A desync is not a network problem.
07:05<Eddi|zuHause>desync is a LOGIC error, not a NETWORK error
07:05<CelestarT42p>sematic error :P
07:06<Yorick>a desync is a bug, something done wrong by someone
07:06<@peter1138>Like using the PRNG within a command test :D
07:06<Brianetta>[11:47] <Yorick> Brianetta: you need a reproducable desync first...
07:06<@peter1138>At least they're obvious.
07:06-!-lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
07:07<Brianetta>Yorick: I have a reproducable desync. Just not a predictable one.
07:07<CelestarT42p>peter1138: or an assignment in an assert
07:07<@peter1138>Have we had that?
07:07<@peter1138>I've seen user patches doing that...
07:07<CelestarT42p>er ... only locally (=
07:07<Dred_furst>then go through the source and see where every call of the PRNG is
07:08<Dred_furst>and strip it down to required calls
07:08<Yorick>Dref_furst: good luck
07:08<CelestarT42p>Dred_furst: and you think that's not already done (=
07:08<Dred_furst>well SOMETHING is broken
07:08<@Rubidium>Dred_furst: duh!
07:08<@peter1138>Not all desyncs are caused by the PRNG, but the PRNG is used to detect them.
07:08<Dred_furst>and the likely culprit is your PRNG
07:09-!-Doorslammer [] has joined #openttd
07:09<Yorick>192 source lines containing Random()
07:09<@Rubidium>Dred_furst: as peter1138 said, the PRNG is used to detect the desyncs. It hasn't been the cause of a problem for the last few years
07:09<CelestarT42p>peter1138: someone might use the iPRNG where the nPRNG is used (or is that still used?)
07:10<@Rubidium>the last few years where things like slight differences in implementations of external libraries
07:10<Brianetta>If the server doesn't send some pertinent information in the network save routine, and that information can influence any change in the state of the game, a desync is inevitable.
07:10<@peter1138>CelestarT42p, yup. They're easy to spot though :)
07:10<@Rubidium>or NewGRFs fracking up
07:10<CelestarT42p>peter1138: point taken
07:10<CelestarT42p>the problem with NewGRFs is that they dig deeply into the engine
07:10<CelestarT42p>VERY deeply
07:10<@Rubidium>Dred_furst: but please review all 150 thousand lines of actual code and find the desync that way
07:10-!-lobster_MB [~michielbr@] has joined #openttd
07:10<Eddi|zuHause>or caches where the order of insertion is relevant
07:10<Brianetta>Rubidium: Shouldn't a newgrf frack up in exactly the same way on client and server?
07:11<Brianetta>The game is deterministic, isn't it?
07:11<@peter1138>Cache-coherency problems are spotted by the server and original clients staying on, but subsequent clients desyncing.
07:11<@peter1138>Hence "reload the server" fixes them.
07:11<Brianetta>My server first started desyncing people who weren't me
07:11<Brianetta>When I eventually disconnected, I also got desynced
07:11<@peter1138>Until you disconnect and rejoin, and then you will desync too :)
07:11<@Rubidium>Brianetta, easy way to cause a desync: make NewGRF behave differently before 1970 than after it and start the server before 1970
07:11<Yorick>your server stopped trusting strangers
07:12<Brianetta>unfortunately, reloading the server didn't fix it
07:12<Yorick>Rubidium: ttrs :)
07:12<Brianetta>Rubidium: Wow...
07:12<Yorick>openttd didnt exist back in 1970
07:12<Yorick>and neither did I
07:13<CelestarT42p>Brianetta: computers are deterministic, unless you have SBE due to SCR or GCR
07:13<Eddi|zuHause>Yorick: it's fine as long as it is only graphically (e.g. road replacements)
07:13<CelestarT42p>or similar events
07:13<Eddi|zuHause>cosmic dust!
07:13<Yorick>Eddi: ttrs got era's
07:13<CelestarT42p>Eddi|zuHause: "SCR" and "GCR" is that :P
07:14<Eddi|zuHause>i figured ;)
07:14<Eddi|zuHause>Yorick: yes, but they are deterministic...
07:15<Eddi|zuHause>houses store the year they were built in
07:15<Eddi|zuHause>roads don't
07:15<CelestarT42p>Rubidium: heh? how will that TTRS example cause a desync?
07:15<Yorick>we need NoGRFs, grfs scripted in squirrel :P
07:15<Brianetta>What happens in 1970?
07:15<Brianetta>Specifically, what happens in 1970 that doesn't happen on both sides of a net connection?
07:15<planetmaker>new roads IIRC
07:15<CelestarT42p>good Q
07:16<@peter1138>Just graphical.
07:16<planetmaker>and other buildings
07:16<@peter1138>Just the roads. Everything else is controlled by NewGRF.
07:17<@peter1138>Unless it changes bridge speeds too, but I don't think it does, heh...
07:17<Eddi|zuHause>Brianetta: newgrfs can load different things depending on if they were loaded before or after a certain year. if you load the grf in 1969 and play for two years, it looks different than if you join in 1971
07:17<planetmaker>I don't think it's modifying bridge speeds as function of time
07:18<@peter1138>The bridge styles change, certainly.
07:18<planetmaker>hm... :) I won't contradict the newgrf guru :P
07:18<Brianetta>"as a function of time" would be fine
07:19<Yorick>oh spiritual descendant of the newgrf gods, load us with your wisdom
07:19<Brianetta>If it's determining behaviour by the date *at which the grf is initialised* there's trouble
07:19<@Rubidium>too bad it's "as a function of time at game load"
07:19<Eddi|zuHause>Brianetta: as long as there are no varaction2s, the "function of time" can only be calculated on load
07:20<Brianetta>Perhaps the newgrf state should be in the save game, then, and the newgrfs themselves not initialised except at game creation time.
07:20<CelestarT42p>Eddi|zuHause: that means the TTRS is not usable in the network?
07:21<@peter1138>Rubidium, we could fudge it to be 'at time of game start' ;)
07:21<Eddi|zuHause>CelestarT42p: i don't know... like it's said, if it really only replaces graphics, it should be fine
07:21<@peter1138>But I don't think TTRS changes anything apart from cosmetics.
07:22<Ammler>peter1138: newcargo?
07:22<Brianetta>I'm wondering if the grvts.grf set does this
07:22<@peter1138>I mean based on date of game load.
07:23<CelestarT42p>peter1138: so what's the plan for furthering cargodest?
07:23<CelestarT42p>maybe I should write something about it on the wiki or so
07:23<@peter1138>We could make any GRF that uses action 7/9/D/etc using a date variable be marked as unsafe...
07:23<@peter1138>CelestarT42p, fixing it ;)
07:24<@peter1138>Assuming it's not already.
07:24<CelestarT42p>peter1138: what's broken? :P
07:24<@peter1138>On my old game, no cargo would load at all until I changed everything to use destinations.
07:25-!-lobster_MB [~michielbr@] has quit [Ping timeout: 480 seconds]
07:25<CelestarT42p>peter1138: cannot reproduce?
07:26-!-ecke [~ecke@] has joined #openttd
07:27-!-Sacro [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has joined #openttd
07:28<CelestarT42p>peter1138: how about showing the destinations in the "total cargo" display. We gonna do that?
07:28<CelestarT42p>g2g anyway
07:28<CelestarT42p>cu later
07:28-!-CelestarT42p [] has quit [Quit: leaving]
07:31<Progman>thats my request \o/
07:31-!-Sir-Bob [] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
07:32<Eddi|zuHause>peter1138: in the train details view
07:32<@peter1138>I was going to say I didn't have all his changes, heh...
07:33<@peter1138>Which might be why it didn't work properly.
07:33<Yorick>shouln't strgen be included in bundles?
07:34<Eddi|zuHause>Yorick: no, why?
07:34<Yorick>it's missing with nightlies
07:35<Yorick>people that want to make their own language files can't
07:35<Eddi|zuHause>why would it be included? it's not necessary to run the game
07:35<Eddi|zuHause>plus, strgen hardly ever changes
07:35<@Rubidium>Yorick: english.txt isn't in the nightlies either
07:36<@Rubidium>ergo: they can't anyway when you include strgen
07:36<Yorick>Eddi: well it did
07:37<@Rubidium>nobody seems to have missed it
07:38<Eddi|zuHause>Yorick: on average, it changes once every 1000 revisions
07:40<Yorick>Rubidium: I have
07:40<@Rubidium>after 1.5 years
07:41<Eddi|zuHause>Yorick: the amount of people who need strgen and don't compile themselves is negligible, it would not be worth the effort
07:41-!-Bjarni [] has quit [Quit: Leaving]
07:42<@Rubidium>furthermore the strgen made by the compile farm's useless for most people as it's a linux version of it
07:43<@peter1138>Translators should use WT2.
07:44<@peter1138>Is that opened yet?
07:44-!-lobster_MB [~michielbr@] has joined #openttd
07:45<Yorick>peter1138: so everyone except the translators is excluded from getting a translation into openttd
07:46<@peter1138>No. If you getting a translation into OpenTTD then the idea is you become a translator...
07:46<@peter1138>WT2 (I believe) tracks things like changes to the English files, which a manual translation might miss.
07:52<Brianetta>Nearly 4/11ths of the way to the OpenTTD server target (:
07:53<Brianetta>Anybody know how many donations have been made? Implication is, what's the average donation?
07:53<hylje>over nine thousand
07:53<Yorick>I wonder if it is needed to compile any *_gui.cpp file for dedicated servers
07:53<Sacro>OpenTTD server target?
07:54<@Rubidium>Yorick: ideologically not, but there're references to the GUI in the normal code that need to be "resolved" first
07:54<Sacro>oh so *thats* why all the donations orudge was on about where coming in
07:54<Yorick>Rubidium: empty functions?
07:54<Ailure>That's alot of donations in a such short timeframe
07:55<@Rubidium>Yorick: that's a quick and lazy fix
07:55<@orudge>Sacro: quite
07:55<Brianetta>I might have been the first to donate
07:55<@orudge>You were.
07:55<Sacro>I has no spare monies at the moment :(
07:55<Brianetta>Which would explain the hug I got off TrueBrain
07:55<@Rubidium>Yorick: as there are quite some functions that are in _gui.cpp that don't belong there and vice versa
07:55<Sacro>Brianetta: that or truebrain saw your picture and took a liking
07:55<@orudge>[12:53:09] <Brianetta> Anybody know how many donations have been made? Implication is, what's the average donation? <-- 35 donations, average £7.66
07:55<Yorick>Brianetta: TrueBrain is strange with hugging and kicking
07:55<@orudge>(most donations tend to be in the order of €10 - €15)
07:56<Brianetta>Cool. So, the average seems to be €10
07:56<Brianetta>A hundred more like that meets the target.
07:56<Sacro>why can people not csount
07:57<dih>Yorick: no TrueBrain is quite reliable with that :-P
07:57<Brianetta>Our goal is to raise £486 (or €0620)
07:57<Yorick>dih: he doesn't kick you...
07:57<Brianetta>orudge: That's €400 to a Unix beard
07:57<Eddi|zuHause>Sacro: same as why people can not wsrite ;)
07:57<Brianetta>since the leading 0 implies an octal number
07:58<Sacro>Eddi|zuHause: hush you
07:58<Ailure>I would easily donate about 500 SEK if I wasn't so poor at the moment.
07:58-!-glx [] has joined #openttd
07:58-!-mode/#openttd [+v glx] by ChanServ
07:58<Ailure>That's about 40 pounds
07:58<dih>Yorick: i have had my fair share of kicks ;-)
07:58<Ailure>...and that's just slightly more expensive how a new game costs here.
07:58<@orudge>Ailure: well, you can donate at any time, not just when there's a fundraiser on :)
07:58<Sacro>i have 192 grivna going spare
07:58<dih>besids, Yorick, is people start kicking you, you should start using your thinker
07:59<Ailure>Orudge: True :P
07:59<Brianetta>This fundraiser has a specific goal, though
07:59<Yorick>dih: he kicked himself yesterday
07:59<dih>yes - also a fun thing to do :-P
07:59<Yorick>whereafter he hugged himself
08:00<Brianetta>Somebody just poured cash in
08:01<@Rubidium>nah, orudge woke up
08:01<Brianetta>You can buy a crap server for colo already (:
08:01<Yorick>wait - orudge has no cash
08:01<Brianetta>Yorick: He has OpenTTD's cash for now
08:02<Yorick>yes, but none of his own
08:02<@orudge>I have enough to get by on.
08:02<@orudge>plus a few hundred quid in trust for OpenTTD
08:02<Brianetta>orudge: Enough to leave the country (:
08:02<@orudge>I've already booked my flight ;)
08:02-!-Forked [] has joined #openttd
08:03*dih loves one way flights
08:03<Sacro>quick, someone delete his destination airport
08:03<@orudge>then I'll circle the north pole for ever!
08:03<@orudge>if you delete the source airport too
08:03*Sacro puts orudge's new destination as an oil rig
08:03<Brianetta>orudge: This is an *OpenTTD* fundraiser.
08:03<Sacro>now you're stuck
08:03<Brianetta>You'll run out of fuel then explode.
08:04<@orudge>maybe we should have a TTDPatch fundraiser instead
08:04<@orudge>I'm less likely to die that way
08:04*dih sends an oil tanker to the oil rig
08:04<Brianetta>No; just trapped on a plane eternally
08:04<@orudge>which i guess would eventually have the same effect
08:04*Brianetta raises an island near the oil rig and builds a long railway station
08:05*dih sends some zeplins
08:05*Yorick unloads av8
08:05<dih>if i get orudge first i get way more money :-P
08:05<dih>Yorick: BAD... never touch grf's in a running game
08:05<Sacro>irc based openttd?
08:05<Forked>=========== ..railwaytrack
08:05*dih scrolls to tile 230
08:06<Yorick>dih: your zeppelins just turned into flying pieces of railwaytrack
08:06<dih>as long as they can transport people and i get (good) money for it, i am happy
08:06<Yorick>no, they transport vehicles now
08:07<Yorick>and can't land without runways
08:07<Brianetta>orudge uses a stretched blue dot for his fund raiser bar
08:07<Brianetta>I'd have used css
08:07<@orudge>well, TrueBrain set that bit up
08:07<@orudge>I just edit it :)
08:07<Ailure>graphical bugs are fun
08:08<Ailure>Like the shops and offices one
08:08<dih>hello Ailure
08:08<hylje>zomg its an Ailure
08:08<Ailure>which you only see if you put outlandish values in the configuration file for subsidaries
08:08<@orudge>and another donation
08:08<Ailure>So instead of a subsidary announcment, the string "shops and offices" comes up
08:09<Ailure>and hello dih
08:09<Yorick>orudge: how much?
08:09<dih>Yorick: a donation ;-)
08:09<dih>every donation is woth the same, even if they differ in value
08:09<Ailure>In other words
08:10<Ailure>I should divide my donations in many parts as possible
08:10<Brianetta>dih: That's rubbish. If you buy them a new server, it's so totally worth more.
08:10<Yorick>dih: "those are the trades that annoy me" :)
08:10<Ailure>to get the most worth out of it
08:10<dih>Yorick: nice quote :-D
08:10<@orudge>somebody needs to donate exactly £3.31, and then we'll have £286. Then somebody needs to donate £103.73, and we'll have £386. Then the same again, and we'll hit £486 :)
08:11<Brianetta>The donation appears to have been for £14.92
08:11<@orudge>that would be incorrect
08:11<Brianetta>so probably not a Sterling donation
08:11<@orudge>the donation was about double that
08:11<@orudge>oh, wait
08:11<@orudge>I added up the wrong column
08:11<@orudge>let's try that again
08:12<@orudge>that's better
08:12<@orudge>well, £28.78
08:12<@orudge>it was a £30 donation
08:13<Brianetta>So, are PayPal stealing cash?
08:13<dih>you lose quite a bit of each donation...
08:13<Brianetta>If I'd known, I'd have wired you the money
08:14<@peter1138>Paypal take fees, yes...
08:14<@orudge>PayPal's fees appear to be about 3.4% + 20p, for UK payments at least
08:14<@orudge>PayPal is the most convenient way of us organising this, however
08:14<@orudge>a few people are donating via bank transfer, however
08:14<@orudge>those won't show up for a few days, of course
08:15<@orudge>and one guy is sending a (British) cheque from New Zealand
08:15<@orudge>so that may take a little while
08:15<hylje>snail mail
08:15<@orudge>if people were to donate more than £55,000, though, the fee goes down to 1.4% and 20p
08:16<@orudge>or 2.9% and 20p for £1,500.01 - £6,000, it seems
08:16-!-lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
08:16<Lachie>my nipples are hard.
08:16<Lachie>hang on
08:16<Lachie>wrong channel.
08:16<Ailure>Get enough Money and Paypal get suspcious and closes your account
08:16<@orudge>Ailure: not happened so far, touch wood :p
08:17<@peter1138>£55,000 would get you a nice server...
08:17<Ailure>Well it's relativtly small amounts, but I do recall that happening with some donation thing some website was running
08:17<Ailure>just as when it ran most succefully, paypal decided to close the account and refused to give back the money
08:18<@orudge>I remember hearing about such things, but they were for sites like Oink
08:18<Brianetta>So PayPal are making £30 or so from us
08:18<@orudge>which weren't necessarily entirely above board
08:18<Ailure>It was massive amount of money too
08:18<@peter1138>Paypal isn't the law though, heh...
08:18<@peter1138>Or maybe they are. :o
08:18<Ailure>It's not a real bank so they can get away with more things sadly.
08:18<Brianetta>Ailure: They're regulated in Europe now, as a bank.
08:18<Ailure>they are
08:18<Brianetta>Used to be the FSA, but now it's a BeNeLux one
08:19<Roujin>say peter, were you the one more into gui things regarding CargoDest development?
08:19<Brianetta>Paypal are hearing a "ch-ching!" and seeing a green figure rise from Owen's account.
08:20<Brianetta>Income: £0.46
08:20<@orudge>well, income £0.88
08:20<@orudge>(20 - 19.12 = 0.88)
08:20<hylje>someone should totally make an animation of that for the fundraiser page
08:20<Brianetta>I was just using a random looks-right figure
08:20<Ailure>[14:19] <Brianetta> Paypal are hearing a "ch-ching!" and seeing a green figure rise from Owen's account.
08:21<Ailure>Imagine how annoying it would in real life if that happened for every transaction event
08:21<Brianetta>I'd be crying tears of joy
08:21*peter1138 ponders adding that to his payment gateway.
08:21<@peter1138>Plug a soundcard into the servers...
08:21<Ailure>Not if it's as loud as in the game
08:21<Ailure>if you live next to a train station, you get deaf in no time :)
08:22<Ailure>(assuming that the sound scales with distance ;P)
08:23<hylje>peter1138: awesome
08:23<Roujin>peter1138, did you do the route map for CargoDest?
08:23<Ailure>Though it reminds me, that's actually possible with a augmented reality
08:24<Roujin>ooh, me likes augmented reality
08:25<Roujin>always dreaming of some display light enough to fit into glasses without being obstrusive or anything :)
08:25<Brianetta>We're two thirds of the way there in less than a day. Feels good to be part of this crowd.
08:26<Ailure>I just like the idea of mixing reality with virtual things, which can be really useful for some tasks :p
08:26<Sacro>are we a crowd now
08:26<Sacro>i didn't think we'd passed rabble
08:27<@peter1138>Roujin, yes.
08:27<@peter1138>Well, I borrowed it.
08:28<Roujin>peter1138: I've got a small suggestion, why not make it toggleable like the town names?
08:31<Roujin>I mean, the graph seems to be painted over the "Routes" map view as a base, so why not make it like the town names - you can enable or disable the drawing of the route network over any of the map modes as a base
08:31<Roujin>like you can enable/disable drawing the town names over any of the map modes as a base
08:34-!-a1270 [] has quit [Remote host closed the connection]
08:35<@peter1138>Because then you couldn't have the cargo-type toggles.
08:35<Eddi|zuHause>Ctrl+Click on a view button overlays that view ;)
08:35-!-flowOver [] has quit [Quit: Leaving]
08:36-!-orudge [~orudge@] has left #openttd []
08:36-!-orudge [~orudge@] has joined #openttd
08:36-!-mode/#openttd [+o orudge] by ChanServ
08:36<Roujin>hmm true
08:38<Roujin>it's only that the old "Routes" view and the "Route Network" view are very redundant. Route equals Route Network with "Disable All". (+- some yellow dots for the stations)
08:38-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
08:40<Roujin>speaking of "Disable All", the button should probably be depressed if you change to another map view mode - you can switch from industries (disable all) to route network, and the button's still pressed, even if the routes are not disabled.
08:41-!-lobster_MB [~michielbr@] has joined #openttd
08:43<Roujin>though if it were for me, I'd just change those two buttons to "action" buttons rather than "state" buttons, meaning they stay pressed only as long as I hold my mouse down..
08:44<Roujin>or not at all
08:44-!-KritiK [] has joined #openttd
08:48-!-Prof_Frink [] has joined #openttd
08:48-!-Ammler is now known as Ammller
08:50<dih>OpenTTD should do a case insensitive check on playernames
08:50<dih>i.e. it's possible to have a client called 'fibble' and 'Fibble' and 'fibblE'
08:51<fmauNeko>Sysinfo for 'loki': Linux running KDE 3.5.9 "release 49.1", CPU: Intel(R) Core 2 Duo CPU T5450 @ 1.66GHz at 1666 MHz (3333 bogomips), HD: 118/146GB, RAM: 1989/2012MB, 152 proc's, 2.51h up
08:51<@Rubidium>dih: even then it can be fooled rather easily
08:52<Kloopy>But it still makes sense to prevent people who -aren't- trying to abuse the system to be told the name already exists.
08:52<dih>Rubidium: how?
08:52<@Rubidium>dih: dih
08:52<@Rubidium>(ofcourse you need a proper font to see it)
08:53-!-Ammller is now known as Ammler
08:53<FauxFaux> <-- any ideas how to avoid trains being retarded like that? (stable 0.6.2)
08:53<Yorick>servers can also have empty names...
08:54<dih>FauxFaux: that trains order is not to go through that station
08:54-!-lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
08:54<FauxFaux>It's so not.
08:54<FauxFaux>This screenshot's from a previous game, unfortunately, haven't caught anyone do it this game.
08:55<dih>the train is heading to another station, that is why it's doing that
08:55<Yorick>dih: it has to be lost
08:55<dih>at least that is what i have experienced
08:55<Yorick>to show random behavior ;)
08:55<dih>Rubidium: is there nothing that could in theory be dont with those nicks?
08:56<FauxFaux>All those trains are going on a loop through the goods pick-up station and the town to drop off, servicing is off, there's no way it could've got there without going through the drop off iirc. :/
08:56<Yorick>I think you could make them contain alphanumeric symbols only for a start
08:56<FauxFaux>That's rather western-minded.
08:56<dih>the asian clients will love you Yorick for that idea :-P
08:57<@Rubidium>FauxFaux: looks like FS#1473
08:57-!-Brainstorm [] has quit []
08:57-!-Brainstorm [] has joined #openttd
08:57-!-Brainstorm is now known as Guest1531
08:57-!-Guest1531 is now known as Brainstorm
08:58<dih>Rubidium: a case insensitive check on nick names would already be a good start ;-)
08:58-!-DJNekkid_ [] has joined #openttd
08:58-!-DJNekkid_ is now known as DJNekkid
08:58<DJNekkid>is callback 1D/Varaction2 type C6 compatible with extended bytes?
08:59<Yorick>Rubidium: disallowing spaces in names would also be an idea
08:59<dih>Yorick: that is not the problem ;-)
08:59<Yorick>dih: trailing spaces are sometimes hard to spot...
08:59*Rubidium ponders disallowing LIKE %yorick%
08:59<dih>that again is something else
09:00-!-fjb [] has joined #openttd
09:00<dih>Yorick: trailing spaces != spaces in general
09:00<Yorick>leading spaces too
09:00<Yorick>I don't care about other spaces too much
09:00<dih>trim and ci check ;-)
09:01-!-fjb [] has left #openttd []
09:01<Yorick>servers are allowed to have empty names?
09:02-!-fjb [] has joined #openttd
09:05<Eddi|zuHause><FauxFaux> <-- any ideas how to avoid trains being retarded like that? (stable 0.6.2) <- it's the combo signal in the middle, it doesn't do what you want it to do
09:05<FauxFaux>Eddi|zuHause: You sure? It makes sense to me, and I'm pretty sure it's a copy of the stations/double_entrace on the wiki.
09:05<dih>well spotted Eddi|zuHause
09:06-!-devilsadvocate [~user@] has joined #openttd
09:06<dih>but the combo should be fine
09:06<dih>FauxFaux: you only have that screenshot or you have a save too?
09:07<Yorick>basically I think the last_exit_red penalty does not count nicely if it is not the last signal on the trains path ;)
09:07<FauxFaux>Don't have a save, I've never managed to get trains to do it in a controlled environment.
09:07<Yorick>FauxFaux: try making the exit signal 2-way
09:08<Eddi|zuHause>(i think it's the same problem)
09:08<FauxFaux>The screenshots have a far less understandable junction in. :)
09:08<Eddi|zuHause>situation: two trains waiting at the entrances, all platforms are full
09:09<Eddi|zuHause>a train leaves from the left half, combo signal and both entrance signals go green
09:09<Yorick>it is a different situation
09:09<Eddi|zuHause>train from the right sees green entrance and combo signal, starts
09:09<Eddi|zuHause>train from left sees green entrance signal, starts
09:09<@peter1138>DJNekkid: Varaction never uses extended bytes.
09:10<Eddi|zuHause>train from right sees red combo signal, gets lost
09:10<Eddi|zuHause>your stuck situation
09:10<DJNekkid>peter1138: thats what i've thought :)
09:10<FauxFaux>That's a nasty one, yeah, I see now.
09:10<Yorick>the combo isn't needed
09:10<@peter1138>You have the byte/word/dword varaction2 type to achieve that.
09:11<Ammler>FauxFaux: PBS would solve that :-)
09:11<Eddi|zuHause>suggestion: don't have that combo connection there at all, have two separate entrances
09:12<@peter1138>Suggestion, build a bypass route...
09:16<FauxFaux>Yeah, bypass would work, the combo connection is really useful though, as the load-balancing between lines is a pita. :p
09:17<Eddi|zuHause>it certainly is, if you don't make it symmetrical ;)
09:19-!-Osai^zZz is now known as Osai
09:21<Kloopy>What I'd like to see is a queueing system for trains that approach a signal block with red lights... At the moment I believe it's a race to see which gets the green light to enter the block first. I'd like to see it become the train that has been waiting the longest that gets the green light.
09:22<Eddi|zuHause>i think it's which one can start up fastest, and among those, the one with the lowest ID
09:22<Eddi|zuHause>a queueing system is a huge problem...
09:22<Yorick>Eddi: just check the waiting time ;)
09:22-!-KillaloT [] has joined #openttd
09:23<Yorick>but it would mean some performance loss
09:23<Eddi|zuHause>Yorick: you still can't easily decide which trains are waiting for the same section to clear
09:23<Yorick>iterating n^n times
09:23<Eddi|zuHause>yeah... sure...
09:24<hylje>really weak reservations
09:25<Eddi|zuHause>it could work with the reservations, when you take Tekky's suggestion, add the train as a "listener" for a trackbit to clear up, then you can loop through all listeners and check priorities
09:30<Eddi|zuHause>i'm just not convinced that this will be faster than the current system of the train calling the pathfinder each tick while waiting at a signal
09:30<Yorick>dih: it seems like you're happy, right?
09:30<Eddi|zuHause>because then, instead of the number of waiting trains, the number of moving trains is the size of the input
09:31<Eddi|zuHause>for each unreservation, you need to check if a train registered as listener
09:31<dih>Yorick: yes ;-)
09:31-!-Belugas [~belugas@] has left #openttd []
09:31-!-Belugas [~belugas@] has joined #openttd
09:31-!-mode/#openttd [+o Belugas] by ChanServ
09:31*Yorick congratulates dih with <unknown reason>
09:33<dih>hello Belugas
09:34<Yorick>hello Belugas
09:34<@Belugas>hi guys
09:36<Sacro> <- wtf @ Fragster
09:36<Sacro>since when was PBS unrealistic
09:36<Sacro>yes, cos british signalling runs on AND/NOT/OR isgnals
09:38<Ammler>what is more powerful then kill -9?
09:38<Eddi|zuHause>init 0
09:38<Ammler>(only hardware switch, I fear)
09:38<Ammler>Eddi|zuHause: how does init 0 kill a process?
09:39<fonso>init 0 kills all processes
09:39<Eddi|zuHause>it shuts down the computer ;)
09:39<Ammler>if I do that, it will hang on that process for hours :-)
09:39<fonso>it tries to kill them and if that doesn't work it shuts down without killing them
09:39<Eddi|zuHause>init 6, if you want to reboot
09:40<CIA-5>OpenTTD: glx * r14065 /branches/noai/src/squirrel.cpp: [NoAI] -Fix: don't read past the end of a file (could happen for files in tar)
09:40<Sacro>Ammler: isn't kill -15?
09:40<Eddi|zuHause>kill -9 is stronger than kill -15
09:41<dih>Ammler: what process?
09:41<Ammler>Sacro: that is something like "close"
09:41<Sacro>oh right
09:41<Sacro>oh is 15 SIGHUP
09:41<dih>does it have a parent or a child?
09:41*Sacro checks that his luggage is all there
09:41<dih>is it a zombie?
09:41<Sacro>Ammler: sounds like ntfs-3g (fuse)
09:41<Ammler>Sacro: yep
09:41<Sacro>rmmod fuse
09:41<Ammler>but I do not need that windows drive :-)
09:42<Ammler>ERROR: Module fuse is in use
09:42<CIA-5>OpenTTD: glx * r14066 /branches/noai/src/squirrel.cpp: [NoAI] -Revert(r14065): wrong working copy
09:43<Ammler>dih: how do I see that?
09:43<dih>Ammler: ps -AH ?
09:43<Ammler>I have 0 zombies, so not
09:43<dih>glx: lol?
09:44<dih>Ammler: perhaps rmmod has something like a -f option?
09:44<Sacro>shuold do
09:44<Sacro>right, bbl#
09:46<CIA-5>OpenTTD: glx * r14067 /branches/noai/src/squirrel.cpp: [NoAI] -Fix: don't read past the end of a file (could happen for files in tar). This time it's the right one ;)
09:46<+glx>dih: it's not funny
09:47<ln>glx: also remember to declare end of discussion after not funny.
09:47<dih>i did add a questionmark :-P
09:47<dih> <- AWSOME!!!
09:48<Yorick>not bad
09:48<Eddi|zuHause>a little bit buggy
09:49<Yorick>I don't like jquery
09:49<Eddi|zuHause>the names don't always appear and disappear correctly
09:49<Yorick>what names?
09:49<Ammler>hmm, hardware switch did the job :P
09:50<Ammler>but still strange :-)
09:53-!-Golfgeo [~ice@] has joined #openttd
09:53<Golfgeo>Hi all
09:54<Golfgeo>Although not nice I would like to force electric trains via a cheat. Anyone know how to do this?
09:55<Eddi|zuHause>there's a "disable electric rail" switch, if that is what you want
09:56<devilsadvocate>hi.. is there any way i can enable automatic vehicle renewal on a saved game?
09:57<Golfgeo>Eddi, Well, thats not the thing I mean. I would like to disable steam and diesel locks...
09:58<+glx>Golfgeo: write a newgrf
09:58<Golfgeo>Sorry for that last time, wrong window
09:58<Golfgeo>glx: hmm, interesting :-)
10:01-!-mikl [] has quit [Quit: Leaving...]
10:01<devilsadvocate>its getting a bit of a pain replacing about 150 vehicles every few years ... :(
10:02<Brianetta>devilsadvocate: It's all in the options menu
10:02<Brianetta>You want "configure patches!
10:03<devilsadvocate>Brianetta, i tried that. It seems to be resetting every time i actually start/load the game
10:03<Brianetta>Yes. Change it *after* you load the game.
10:03-!-Sacro_ [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has joined #openttd
10:03<Brianetta>Click-hold the spanner for the menu.
10:04<devilsadvocate>will do
10:04<devilsadvocate>got it
10:04<devilsadvocate>thanks :)
10:05<devilsadvocate>now i can spend some time hunting down all the lost trains :P
10:06*Brianetta disables breakdowns and servicing
10:06<Brianetta>My networks have only one depot
10:06<Brianetta>Usually quite an ornate piece of eyecandy staion surrounds it.
10:07<devilsadvocate>ive got about 40 stations connected to each other
10:08<devilsadvocate>the gridlocks are beautiful, sometimes
10:08-!-Sacro [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has quit [Ping timeout: 480 seconds]
10:09<devilsadvocate>it was especially interesting converting the whole thing to maglev
10:10<Eddi|zuHause>i have not done that in years
10:10<Eddi|zuHause>it does not make any sense with most newgrf sets
10:10<Brianetta>Maglev is ugly.
10:10<Eddi|zuHause>plus, i rarely reach that stage anyway, with the daylength patch
10:11<devilsadvocate>i havent used any newgrfs yet.. just re-found openttd recently
10:11<Brianetta>I sometimes have one short maglev track around a town.
10:11<devilsadvocate>i agree with ugly
10:11<Brianetta>A whole network's asking a bit much, though.
10:11<devilsadvocate>i can show you the saved file if you want :P
10:12<devilsadvocate>they're expensive, but with passengers they seem to pay back for themselves with the speed
10:12<Brianetta>Wouldn't do me much good, here at work
10:13<devilsadvocate>ah, ok
10:13<Brianetta>King of newgrf sets
10:13<Brianetta>Everything Pikka touches is fabulous
10:13-!-Yorick [] has quit [Quit: Poef!]
10:13<Eddi|zuHause>i like the DBSetXL more ;)
10:14<Brianetta>You would (:
10:14<Brianetta>A train doesn't quite look right without yellow ends, though
10:15<Eddi|zuHause>i never could get warm with the uk engines...
10:15<dih>now that could only come from a brit
10:15<hylje>daamn wankar
10:15<Brianetta>I'm still not sure *why* yellow
10:15<Brianetta>of all the colours
10:15<Brianetta>Flourescent pink would be more visible
10:16<hylje>a bit too visible
10:16-!-dvo [] has quit [Read error: Connection reset by peer]
10:16-!-divo [] has joined #openttd
10:16*devilsadvocate is used to dull red engines
10:16<devilsadvocate>oh, and they should be dirty, too. doesnt look like they're working oterwise
10:18-!-dlunch [~dlunch@] has joined #openttd
10:20-!-dvo [] has joined #openttd
10:20-!-divo [] has quit [Read error: Connection reset by peer]
10:21<Tekky><Eddi|zuHause> i'm just not convinced that this will be faster than the current system of the train calling the pathfinder each tick while waiting at a signal, because then, instead of the number of waiting trains, the number of moving trains is the size of the input; for each unreservation, you need to check if a train registered as listener <-- It is a lot cheaper to make a lookup in the...
10:21<Tekky>...list of listeners than to make a pathfinder call.
10:22<Eddi|zuHause>yes, but you might end up making the lookup more often than the pathfinder call
10:22<Eddi|zuHause>especially when trains are not waiting
10:23<Tekky>yes, you certainly will. But a pathfinder call is about 10,000 times more expensive than a simple lookup :)
10:24<Eddi|zuHause>well, then do it ;)
10:24<Tekky>That is what I am working on :-) But I'm having trouble understanding YAPF, because it makes heavy use of C++ templates :-(
10:26<Eddi|zuHause>why would you look that deep into yapf? just check the reserve and unreserve functions of YAPP, and hook the listener callbacks there
10:26<CIA-5>OpenTTD: rubidium * r14068 /trunk/src/console_gui.cpp: -Fix (r14056): MSVC doesn't support typeof.
10:27<Tekky>I plan to store all reservation information in the YAPF cache, i.e. I want all track segments to be cached fully by YAPF (as already is partially the case) and I want this cache to also store PBS reservation information, so that reservations are on entire track segments instead of individual track pieces. This will make reservations more efficient.
10:28<Tekky>This will also make it easier to store different reservation types for the same track segment, because they won't have to be stored in the map array anymore.
10:29<Eddi|zuHause>i don't think that will work, because you can have multiple signals per segment
10:29<hylje>do you intend to also cache potential segments at forks?
10:30<Tekky>I think this will be an important prerequisite to implementing lookaheads (which can be simply stored as a special type of reservation) and "weak" reservations, as described in my wiki article:
10:30-!-dlunch_ [~dlunch@] has joined #openttd
10:31<Tekky>hylje: I define a track segment as a stretch of track with no signals or switches(=forks) in between.
10:31-!-lobster_MB [~michielbr@] has joined #openttd
10:31<Tekky>This should be the base unit for PBS reservations.
10:32<Tekky>Instead of individual track pieces.
10:33<Tekky>However, as far as I can tell, the YAPF cache currently defines a track segment as a piece of track with no switches(=forks) in between, so a YAPF track segment is not split by signals.
10:33<hylje>so it's not 1:1
10:33<Eddi|zuHause>worse: yapf segment starts on a switch, so if you reserve that, people can not use the switch for another direction after your train passed
10:34-!-Mchl [] has joined #openttd
10:34<Tekky>Yes, I am thinking of keeping YAPF segments and defining sub-segments for PBS reservations.
10:34-!-dlunch [~dlunch@] has quit [Ping timeout: 480 seconds]
10:35<Eddi|zuHause>good luck with that ;)
10:36<Tekky>Eddi: I think YAPF segments start on a particular track piece, so it's no problem if that track piece is part of a switch, as long as only one track piece of the switch is part of the YAPF segment.
10:38<Eddi|zuHause>Tekky: i mean if the train left the switch, but is still in the segment, the next train cannot reserve the switch towards another segment, because it crosses the still active reservation
10:40<@peter1138>Sacro_, best quote ever :D
10:42<Tekky>Eddi: What you say "segment", do you mean "YAPF segment" or what I call "sub-segment"?
10:43-!-lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
10:43<Tekky>Eddi: Ah, my above question is irrelevant.... just a moment....
10:43<Eddi|zuHause>doesn't matter...
10:44<Tekky>Eddi: Just a moment, let me make a screenshot..... normally I upload files to RapidShare, is there a better place for uploading screenshots?
10:47*Belugas refuses to open the url upper mentioned containing the "realistic" key word
10:48<@peter1138>YAPF segments end at junctions, don't they?
10:48<@peter1138> Comment by Antonio (Fragster) - Friday, 11 January 2008, 13:50 GMT — Edit — Delete
10:48<@peter1138>I think, that it would be great alternative for PBS, which is very unrealistic
10:48<Eddi|zuHause>Belugas: it does not say the r-word, it says the un-r-word
10:48<@peter1138>Just for Belugas :D
10:49<Tekky>Eddi: thx, I will try imageshack
10:49<Eddi|zuHause>Tekky: why not just concentrate on making a "reservation pool", instead of trying to fit it in with the segment cache (which is not saved)?
10:51-!-fjb [] has quit [Quit: Leaving.]
10:52<Tekky>I plan to make the YAPF cache persistent so that it is also saved. The reservation pool and the YAPF cache are very similar, so it makes sense to merge them so that the YAPF pathfinder only needs to access the information of this reservation pool/YAPF cache instead of accessing the map array.
10:53<CIA-5>OpenTTD: rubidium * r14069 /trunk/src/ (fileio.cpp misc_gui.cpp querystring_gui.h): -Fix: silence MSVC 64-bits compile warnings.
10:53<Tekky>It does not make sense to store this information seperately, as the pathfinder needs both and will work most efficiently if they are stored together.....
10:53<@Rubidium>that would explode the savegame size and vastly increase the chance of not being able to join network games due to huge savegames
10:54<@peter1138>It's best not to save things that can be recreated.
10:54-!-dlunch_ [~dlunch@] has quit [Remote host closed the connection]
10:55<Tekky>well, the reservation information will be smaller, if it is stored on a per-segment basis instead of a per-trackpiece-basis....
10:55<Eddi|zuHause>there can be lots of segments
10:55<Eddi|zuHause>especially if people place signals on every tile...
10:56<@peter1138>Or a lot of crossing track.
10:56<Eddi|zuHause>really, i think creating a new pool is the better idea
10:56<@peter1138>How would you reference it?
10:57-!-fjb [] has joined #openttd
10:57<Tekky>Yes, if people place a lot of crossing track, it would indeed be a problem :-(
10:57<Eddi|zuHause>the existing "reserved" bit will only mean "there is a pool item for these coordinates"
10:57<@peter1138>What reserved bit?
10:58<Eddi|zuHause>the yapp track reservation status bits?
10:58-!-dvo [] has quit [Read error: Connection reset by peer]
10:58-!-divo [] has joined #openttd
10:59<@Belugas>what index will be used to access the pool?
10:59<Eddi|zuHause>(tileid, trackbit)?
10:59<Sacro_>peter1138: ?
10:59<@peter1138>Sacro_, unrealistic PBS guy
10:59<@Belugas>pool index needs to be incremental
11:00<@Belugas>i.e.: cannot be forged
11:00-!-Sacro_ is now known as Sacro
11:00<Sacro>peter1138: indeed
11:00<Eddi|zuHause>hm... that makes it a little bit more difficult...
11:01<@peter1138>Plus if you're storing a bit in the map, that pretty much negates the point of not storing a bit in the map...
11:02<@peter1138>(The idea is to reserve a whole segment with one flag instead of having to reserve each tile)
11:02<@peter1138>I don't think it would offer much performance benefit.
11:02<@peter1138>Checking reservation status from the map is probably much quicker than checking a pool via looking at the map, and then via an index, etc...
11:03<Eddi|zuHause>the main problem is increasing the number of types of reservations. you can't increase the number of bits for each reservation type
11:04<Eddi|zuHause>especially if some reservations need to store the train id that made the reservation, and that can be multiple
11:04-!-Doorslammer [] has quit []
11:04<@peter1138>Why would you need to store the 'train id'?
11:04<@peter1138>Following the reservation back to a vehicle is not that complicated.
11:05<@peter1138>Type of reservation... that I don't understand, but you only need 2 bits to flag a different type.
11:05<Eddi|zuHause>it is, if multiple trains are allowed to reserve the same trackbit (for really weak lookahead reservations)
11:07<@peter1138>Store a marker in the vehicles and follow all paths...
11:07<Eddi|zuHause>"all paths" might be the whole map in some cases...
11:07-!-Purno [] has joined #openttd
11:08<@peter1138>That's a stupidly long reservation.
11:08-!-fonso [] has left #openttd [Kopete 0.12.7 :]
11:10<Eddi|zuHause>like: i have a high speed track that gets shared with cargo trains, then when an ICE starts at the station, i need to lookahead-reserve the whole track to force all currently on the track going cargo trains into the next siding to make way
11:11<Sacro>@seen Bj
11:11<@DorpsGek>Sacro: I have not seen Bj.
11:11<Sacro>@seen Bjarni
11:11<@DorpsGek>Sacro: Bjarni was last seen in #openttd 15 hours, 51 minutes, and 46 seconds ago: <Bjarni> goodnight
11:11-!-divo [] has quit [Read error: Connection reset by peer]
11:12<@Belugas>Eddi|zuHause, seems like a better built rail system might be better suited for the task
11:12<@Belugas>personally speaking
11:12<Eddi|zuHause>i was speaking hypothetically ;)
11:13<@Belugas>welll... isn;t it the goal the new proposal is aimed at?
11:13-!-david [] has joined #openttd
11:14<Eddi|zuHause>depending on which proposal you mean, there are different aims that might be slightly overlapping
11:14-!-david is now known as Guest1543
11:15<Eddi|zuHause>people sometimes have difficulties following my suggestions, because i think at least 3 steps ahead ;)
11:15<Tekky>Eddi: I have uploaded an image with 6 track segments, I call them 1R, 1L, 2R, 2L, 3R, 3L. Here is the link:
11:16<Tekky>Eddi: when 1L is reserved, then 2R can be reserved by another train. However, if 1R is reserved then 2r may not be reserved by another train.
11:16<Tekky>2r = 2R
11:17<@peter1138>Signalless operation? :p
11:17<Sacro>for tvg
11:18<Eddi|zuHause>Tekky: the problem is, the segments 1L and 2L overlap on the switch tile
11:18<Tekky>peter1138: I was referring to this statement of Eddi: <Eddi|zuHause> Tekky: i mean if the train left the switch, but is still in the segment, the next train cannot reserve the switch towards another segment, because it crosses the still active reservation
11:18<Eddi|zuHause>so when a train reserved segment 1L, you cannot be sure if it already left the switch tile or not
11:19<Eddi|zuHause>so a second train coming from 3L cannot reserve 2L
11:19<Tekky>peter1138: So we are not talking about signals.
11:19<Eddi|zuHause>Tekky: for this to work, each trackbit on the switch tile must be a separate segment
11:20<Eddi|zuHause>which at least doubles the number of segments
11:20<Tekky>Eddi: If the train that reserved 1L has not left the switch yet, it will still have a reservation on 2L.....
11:21<Eddi|zuHause>no... the train never touches 2L
11:22<Tekky>a train touching a switch will always have at least two segments reserved....
11:23<Eddi|zuHause>train reserved 3L and 1L, but the reservation of 3L will be removed once the last wagon entered the switch tile
11:23<Eddi|zuHause>then only 1L is reserved, but the train is still on the switch
11:23<Tekky>reservations are always in a certain direction.... if a train wants to reserve 1R, it must also reserve 2R and 3L
11:23<Eddi|zuHause>the next train wants to reserve 3L and 2L
11:23<Tekky>However, a train may reserve 1L without making any further reservations.
11:23<Eddi|zuHause>that is not how reservations are done
11:24<Eddi|zuHause>PBS makes reservations for the trackbits it intends to go on, not the ones it crosses
11:25<Eddi|zuHause>another train may not reserve a trackbit if a crossing trackbit is already reserved
11:25<Tekky>well, indirectly, both do the same thing :-) The result is the same.....
11:26<Eddi|zuHause>if you substitute "trackbit" for "segment", this will have the effect i described
11:26-!-frosch123 [] has joined #openttd
11:26-!-Reemo [] has joined #openttd
11:28<Eddi|zuHause>of course, your model might work better if you introduce "using" and "blocking" reservations
11:28<Tekky>ah, yes, I think TTDPatch PBS reserves trackpieces of switches instead of segments - at least that is the graphical feedback provided - so what you describe is simply another way of looking at it.
11:29<Brianetta>Old (NPF) PBS would recalculate reservations en route
11:29<Brianetta>So your train could be on a shared block, and suddenly decide to cross behind another train
11:30<Brianetta>It was pretty cool
11:30<@peter1138>But buggy...
11:30<Tekky>and unrealistic :)
11:31*Brianetta likes realism
11:31<Brianetta>Magic brakes.
11:31<Brianetta>Every train grows them one tile before a red signal.
11:32<Tekky>Eddi: well, my idea was simply to take the existing YAPF cache segments, make them persistent and divide these segments into sub-segments, which are used by PBS reservations. For this reason, I didn't want to work with individual track pieces.
11:33<Tekky>can't wait for the new dedicated server :-)
11:33<Brianetta>orudge: It's fan-bloody-tastic.
11:33-!-lobster_MB [~michielbr@] has joined #openttd
11:33<@Belugas>amazing, i would say :)
11:34<@orudge>plus 3 donations via bank/cheque to come, and a handful of PayPal eCheque payments to clear
11:34<@Rubidium>seems to go even better than the last one
11:34<@orudge>well, last time we asked for £250 or so, and got £312, as people donated quicker than I could update the page
11:35<@Rubidium>in 20 hours; the fundraiser is now also open for ~20 hours
11:35<Tekky>Eddi: Yes, the segments a train is actually on should have a different reservation type than the segments that a train is merely blocking.....
11:35*Sacro feels an urge to donate
11:36<@orudge>Sacro: cash only, please, no sperm
11:36<Eddi|zuHause>it might work out, but i'm still not convinced of reusing the yapf cache
11:36<Sacro>orudge: cash?
11:37<Sacro>you going to come collect?
11:37<@orudge>well, cash as in money
11:37<Tekky>Eddi: Also, the segment that a train plans to stop on should also have a different reservation type than segments that the train will merely pass through, because the latter reservation type will not conflict with "weak" reservations, but the former reservation type will.
11:38<Tekky>Eddi: It would be impossible to store all of these different reservation types in the map array, so we need an external graph.
11:38<Eddi|zuHause>yes. you explained that before
11:42<Tekky>Eddi: Furthermore, I think every reservation will require reference counting, because a train may be blocking trains from entering the same track segment for several different reasons. For example, two different segment reservations may cause the same track segment to be blocked, so when one of these reservations is cleared, the blocked segment must remain blocked until the second reservation is a
11:42<Tekky>lso cleared. For this, all reservations require reference counting.
11:42<Tekky>a lso = also
11:43<Tekky>Eddi: such reference counting would certainly not fit in the map array :)
11:44<Eddi|zuHause>you're beating a dead horse... i understand very well why the map array reservation is not extendable
11:44*Belugas pats poor map array
11:45<Eddi|zuHause>my questioning concerned reusing the yapf cache vs. creating a separate reservation cache
11:45<Eddi|zuHause>because the yapf cache does not need storing, the reservation cache does
11:45*Rubidium wonders how useful the YAPF cache is for NPF or OPF
11:45<Eddi|zuHause>plus, like you said, yapf does not care about signals
11:48<Tekky>Eddi: For example, in my picture, a train having reserved both 1R and 3R will be blocking 2R, because both 1R and 3R cause 2R to be blocked. So the "blocking reservation" reference count of 2R will have to have a value of 2, which is decremented to 1 when 1R is cleared and decremented again when 3R is cleared. After that, the reference count of the "blocking reservation" will be 0, so also...
11:48<Tekky>...this "blocking reservation" will be cleared.
11:49<CIA-5>OpenTTD: rubidium * r14070 /branches/noai/ (12 files in 4 dirs): [NoAI] -Fix: silence MSVC 64 bits warnings.
11:49<Tekky>Eddi: Well, the YAPF cache and the reservation data is very similar, because both are graphs of the track layout.
11:50<Tekky>Eddi: Therefore, it makes sense to combine them, I believe.
11:50-!-Gekz [] has joined #openttd
11:50-!-Gekz [] has left #openttd []
11:50<@Rubidium>Tekky: but remind yourself of the fact that NPF and OTP/OPF do not use the YAPF cache
11:51-!-Gekz [] has joined #openttd
11:51<Eddi|zuHause>but they are different for exactly the reasons mentioned: signals play a role, persistency, using the YAPF cache without using yapf
11:51<Eddi|zuHause>these are all reasons to not combine them
11:51-!-Farden123 [] has joined #openttd
11:53<Tekky>Eddi: Ok, the YAPF cache only has to be persistent for track segments in PBS blocks.....
11:53<Eddi|zuHause>now you're getting silly...
11:54<Brianetta>All signal blocks are PBS blocks in my games.
11:54<Noldo>do the original pathfinding methods for rvs, trains and ship share any code?
11:55<Tekky>Eddi: If I want to store the PBS information inside the YAPF cache instead of the map array, then the YAPF cache has to be persistent for PBS blocks? What is "silly" about that?
11:56<Tekky>Eddi: That seems like an obvious statement to me, or am I mistaken?
11:57<Tekky>Brianetta: Yes, I also exclusively use YAPP signals, because standard signals and YAPP signals do not mix very well, I'm afraid :-(
11:58-!-Farden [] has quit [Ping timeout: 480 seconds]
11:58<@Rubidium>they work fine for me
11:58<Sacro>Tekky: mix fine here
11:58<Sacro>using all PBS is unrealistic
11:59<dih>my BUNNY is over the ocean....
11:59<@Belugas>mmh... so i should start doing that
11:59<Noldo>dih: what?
11:59<Brianetta>I find that they mix fine; I just can't be bothered to switch signal types.
11:59<dih>my BUNNY is over the sea
11:59<Brianetta>There's no specific advantage to having regular signals.
12:00<Sacro>Brianetta: less CPU usage
12:00<Brianetta>Sacro: Unrealistic? Justify that claim.
12:00-!-fjb [] has quit [Quit: Leaving.]
12:00-!-ProfFrink [] has joined #openttd
12:00<Sacro>Brianetta: in UK signalling you tend to have automatic signals where there is no junction
12:01<Eddi|zuHause>along a straight track, "realistic" would be combo signals
12:01<Eddi|zuHause>the ones from my suggestion
12:01<Eddi|zuHause>i.e. a main signal and an advance signal combined each km
12:01<Brianetta>Sacro: Nevertheless, junctions are all over the place (normally crossovers)
12:02<Tekky>If a train has to wait in front of a standard (non-YAPP) signal in a mixed signal block on one-way-track, then after some time, the train will reverse, but it will be unable to find a route due because it wasn't supposed to reverse on one-way track. Only after reversing again will the train be able to find a route. This unwanted automatic train reversal is the primary cause of traffic jams...
12:02<Tekky>...with me, so I exclusively use YAPP signals where automatic train reversal can be deactivated.
12:02<Brianetta>and all UK signals I have seen remain red until a train is given permission to proceed
12:02<Sacro>Brianetta: true
12:02<Brianetta>which is exactly what advanced signals do
12:02<Sacro>a lot do clear to green when the line is clear
12:02<Sacro>esp on the ECML
12:03<Brianetta>Tekky: Always join regular and PBS with one-way PBS
12:03<Eddi|zuHause>Brianetta: does not prevent the trains from turning around
12:03<Brianetta>Sacro: No; they're green because a train's coming
12:04<Brianetta>Eddi: That's a problem with regular signals anyway
12:04<Sacro>Brianetta: if a signal has a black plate with a white line then it will clear to green when the line is clear
12:05<Sacro>however some have an emergancy button to hold them at red
12:05<Eddi|zuHause>Sacro: but then you can't have bidirectional traffic on the track
12:05<Sacro>Eddi|zuHause: not a lot of the UK is equipped for bidi
12:06<Brianetta>All the ECML roads up here are bi-directional
12:06-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
12:06-!-ProfFrink is now known as Prof_Frink
12:06<Sacro>Brianetta: are you sure?
12:06<Sacro>i didn't think any of the ECML was
12:06<Brianetta>Sacro: yes.
12:07<Brianetta>I've been held up by a freight train going our way, that broke down when it switched in front of us.
12:07<Sacro>that's not bidi
12:07<Brianetta>It was on the other road.
12:07<Brianetta>It was travelling south, same as us, toward york.
12:07<Sacro>could just be up slow, up fast, down fast, down slow
12:07<Brianetta>It switched to our side, but by the time we got to where it was, it had conked out.
12:07<Sacro>it might have switched from slow to fast
12:07<Brianetta>There are only two roads
12:08<Sacro>you might have been authed for a wrong side manouvre
12:08<Brianetta>Or the freight was.
12:08<Brianetta>They're bidi, though
12:08-!-Farden123 is now known as Farden
12:09<Brianetta>My best man used to manage regional maintenance when Balfour Beatty had the contract from Railtrack
12:10<Brianetta>Trains have even been known to race each other (:
12:10-!-Gekz [] has quit [Ping timeout: 480 seconds]
12:10<Brianetta>One driver, doing so, missed three detonators. Luckily he also missed the crew working on the line further down.
12:11-!-devilsadvocate [~user@] has quit [Quit: Leaving]
12:11<Brianetta>Think he's no longer driving.
12:11<Tekky>is it true that a call to NotifyTrackLayoutChange(TileIndex tile, Track track) invalidates the entire YAPF cache?
12:12<Eddi|zuHause>"three detonators" being the "emergency stop" signal?
12:12<Brianetta>Yes. Well, even one is. Three is to make sure it's noticed.
12:12<Brianetta>If your wheels go bang, you stop.
12:13<Eddi|zuHause>Tekky: yes, that's exactly what the function is supposed to do
12:13<Sacro>plans for grade seperation at hitchin
12:13<Tekky>Eddi: I would have thought that it would only invalidate those segments that were changed. But it seems to ignore both parameters and invalidates the entire cache.....
12:16<Tekky>Eddi: I guess I must change this, too :)
12:16<Tekky>Hehe, there is so much stuff in OpenTTD that I would like to change. ;-)
12:16-!-trainboy2004 [] has joined #openttd
12:17-!-trainboy2004 [] has quit []
12:17-!-TinoM [] has joined #openttd
12:19<Eddi|zuHause>really, i mean it... combining the YAPF and reservation caches is a bad idea...
12:21<Tekky>You may be right... I am currently studying the YAPF cache to see exactly how it is implemented....
12:22<@peter1138>The YAPF cache that is not used for NPF or OPF...
12:22<@peter1138>Still not...
12:22<@Belugas>[12:16] <Tekky> Hehe, there is so much stuff in OpenTTD that I would like to change. ;-) <-- start a fork
12:22<@Belugas>provide patches
12:22<@Belugas>do something!
12:22<Tekky>However, for the PBS reservations, I will need to maintain a graph of the track layout's segments anyway, so it seems reasonable to use this graph also as a YAPF cache.....
12:25<Tekky>Belugas: yes, I am doing something, I am currently studying YAPF in detail :-)
12:26<@Belugas>you are braver then me
12:26<Tekky>Maybe this graph does not have to be stored in the savegame, as it can be reconstructed at any time. Just the individual segment IDs must remain the same after a reconstruction, otherwise the trains' reservations will refer to the wrong track segments.
12:26<@Belugas>or having a lot more time then me
12:27<Tekky>I've been wanting to implement bi-directional double track for a long time now. I wrote the corresponding wiki article already more than a year ago:
12:29<frosch123>and both ttdp's and ottd's are in parts based on it :)
12:30<Tekky>Most of my suggestions I made at that time have now been implemented by YAPP, and yes, TTDPatch "through signals" are also based on my ideas. However, in order to support bi-directional double track, also "weak" reservations/unsafe waiting locations must also be supported :(
12:30<Tekky>and also a train scheduler/prioritizer would have to be implemented.....
12:32<Tekky>All of these different reservation types strong/weak reservations and lookahead (a type of reservation used by a train prioritizer) will have to be implemented.... For this, I must make the PBS reservations stored outside the map array.
12:33<Eddi|zuHause>i just feel the urge to throw shunting reservations into the pool ;)
12:33<@Belugas>do it do it do it
12:33<Brianetta>Tekky: You're going to have to do a lot of work to figure out which train gets to strengthen its reservation.
12:34<Brianetta>I just want to see express orders (:
12:34*frosch123 wonders whether he should bother about preserving vehicle news when vehicles are sold and bought by autoreplace...
12:35<Tekky>Yes, I know, and it will be very CPU-intensive.... therefore, the track layout will have to be heavily cached......
12:35-!-Bjarni [] has joined #openttd
12:35-!-mode/#openttd [+o Bjarni] by ChanServ
12:37<Tekky>Brianetta: Well, as a start, I think it should be enough if a train has an additonal lookahead of 1 or 2 signals and if a conflict is detected with another train, the train with the higher priority is given right of way. If both trains have the same priority level, the train with the higher maximum speed is given priority. I think that would be good enough for a start.
12:38<Tekky>a more intelligent train conflict resolution scheme can be developed later.....
12:38<Brianetta>What determines priority?
12:38<Brianetta>Also, what determines conflict?
12:38<Tekky>I guess a train's priority level should be set in the train's orders....
12:39<Brianetta>If we're going to make orders determine priority, it makes sense to have that priority simply mean "attempt to reserve an additional path if possible"
12:39<@Bjarni>you mean like you can set a train with full load to have higher priority than the returning empty ones?
12:39<Brianetta>Bjarni: My take was to have an order modifier, so yes
12:40<Brianetta>An "express" button along with non-stop and full load and so on
12:40<Eddi|zuHause>a train's reservation priority should decrease with the amount of signals passed
12:40<Tekky>as I said, every train has an additional lookahead of 1 or 2 signals. If two trains' lookaheads enter the same track segment, a train conflict is detected and one train will be given right of way, based on the train conflict resolution scheme.
12:40<Brianetta>All it would do, very simple, is reserve an additional path, if possible.
12:40<Brianetta>First come, first served.
12:41<Brianetta>Im fine with my unimportant trains not looking ahead.
12:41<Brianetta>It saves memory and CPU.
12:41<Tekky>Bjarni: yes, a train will full load should normally be set to also have a higher priority than empty trains.
12:41<Eddi|zuHause>so a train with priority 5 would look 5 signals ahead, but that last signal he would have a priority of 1, so a train with priority 2 could supercede that
12:41<Brianetta>That could work, Eddi
12:41<Eddi|zuHause>the priority of the reservation would increase when the train approaches
12:41<Brianetta>but it's the current order that should have priority, not the train
12:41<Tekky>not bad ideas....
12:42<Eddi|zuHause>yes, priorities should be order based
12:42<Brianetta>and priority shouldn't be tied to "non-stop" or "full load"
12:42<Brianetta>It should be separate
12:42<Brianetta>My coal trains full load, and my passenger trains don't
12:42<Brianetta>but I never want my coal trains muscling through
12:42-!-trainboy2004 [] has joined #openttd
12:43-!-trainboy2004 [] has left #openttd []
12:43<Tekky>anyway, all of these ideas require in my opinion a rewrite of the way reservations are stored....
12:43<Eddi|zuHause>but it's relatively independent from advance signals
12:44<Eddi|zuHause>because those just change the way "strong" reservations are made
12:44<Brianetta>advance signals don't really excite me...
12:44<Tekky>I disagree. There is no point in having lookahead reservations with standard non-YAPP signals, in my opinion.
12:44<Brianetta>Tekky: My original proposal requires no changes to storage
12:45-!-fjb [] has joined #openttd
12:45<Eddi|zuHause>Tekky: advance, not advanced ;)
12:45<@Bjarni>we have free bits in the order struct
12:45<Tekky>Eddi: Oh, I thought you just made a typo :)
12:45<Brianetta>an order marked "express" simply means "try to reserve more track"
12:45-!-welshdra-gone is now known as welshdragon
12:45<Brianetta>Eddi: Can also call them "distant signals"
12:45<@Bjarni>actually we have 16 in a row. A single byte should be enough
12:45<Eddi|zuHause>Brianetta: that could work ;)
12:46<Sacro>i want advance signals
12:46<Brianetta>Sacro: Terminology (:
12:46<@Bjarni>Sacro: you should describe what you want it to do in the game
12:47<Eddi|zuHause>the problem is "advance" is too similar to "advanced", people will always confuse those
12:47<Brianetta>I don't care about advance, or distant, signals because I dpn't want *track* to have priority. I want *orders* to have priority.
12:47<Sacro>Bjarni: if it is on then a train should slow down
12:47<Tekky>well, actually the concept of distant signals does sound interesting, however, there would have to be about 10 different aspects, I'm afraid, because train speed varies very much in OpenTTD :(
12:47<Sacro>Tekky: 10?
12:47<Sacro>we aren't germans
12:47<Brianetta>10 is a binary number
12:48<@Bjarni>here an advance signal can have 3 different states
12:48<Brianetta>Sacro: I say worry about distant signalling only when a train loses its magic brakes.
12:48<Sacro>Brianetta: yes, true
12:49<@Bjarni>"reduced speed (including stop)", "full speed" and "full speed all the way though the station (this is used at entrances to stations)
12:49<Sacro>Bjarni: here it is two
12:49<Sacro>it is on. or off
12:49<Brianetta>End of line, red signal, backwards one-way signal. All of these make a train stop magically.
12:49<Brianetta>Stop that happening, and then we'll need distant signals.
12:49<Tekky>how fast are trains allowed to go if they are using distant signals? Here in Germany, train speeds are limited to 160 km/h when using distant signals. Trains with higher speeds require direct speed control through Centralized Traffic Control and train signals are ignored.
12:49<Brianetta>Actually, even then it'll be optional, since a train cean see the next signal even if it's around a bend.
12:50<Brianetta>Tekky: Depends. When they were invented, it was for steam and semaphores. In the UK, a yellow semaphore mirrored a red one further in advance.
12:50<Eddi|zuHause>Tekky: the solution to that is forcing the train to reserve more signal blocks ahead
12:50<Brianetta>Usually because the red one was in a forest, or around a cliff.
12:51<Sacro>Brianetta: nope, distants where always used
12:51<Brianetta>Sacro: When they were invented, no
12:51<Sacro>if you can't see the main then you have a repeater
12:51-!-lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
12:51<Eddi|zuHause>it could also be to make a speed limit of 160km/h on conventional rail, and add a special "high speed" railtype
12:51<Brianetta>distant === repeater, originally
12:52<@Bjarni><Sacro> it is on. or off <-- for safety reasons signals can't be "off" here. How can you tell the difference between "no danger" and "no power"?
12:52<Sacro>yeah, but not now
12:52<Sacro>Bjarni: oh right
12:52<Brianetta>Sacro: The game starts well before now (:
12:52<Sacro>on = red
12:52<Sacro>off = green
12:52<Tekky>Eddi: Hmmmm, nah, that may be a bit too specific to German Railway......
12:52<Sacro>Brianetta: i don't go further back than 1950 :p
12:52<Sacro>no trains existed before then
12:52<Brianetta>My server starts in 1920
12:53<Brianetta>I'd have it in 1890 if there were decent trains around
12:53<Tekky>Eddi: Should the high-speed railtype also use signals?
12:53<Brianetta>except the towns look a bit over-modern
12:53<Sacro>Tekky: well tgv doesn't
12:54<Tekky>Eddi: I mean distant signals? Or should the train's speed be controlled directly by Centralized Traffic Control?
12:54<Tekky>Eddi: Of course, main signals must always be placed....
12:55<@Bjarni>we have two kinds of signals that can be completely off. One is at crossings if the crossing state is told by an advance crossing signal. The other type is on small railroads where you have to press a button to get the train to stop. Light = the train should stop, no light = move on
12:55<@Bjarni>the crossing signal is slowly being replaced by a new type with lights for all states
12:55<Eddi|zuHause>Tekky: on german high speed lines, conventional signals are placed (in bigger distance than the automatic blocks) when conventional trains without LZB are supposed to use the track
12:56<@Bjarni>and I don't think the stop light is a safety device
12:56*peter1138 ponders running a network game...
12:56<Eddi|zuHause>Tekky: but i have no idea how to properly include that in the game
12:57<@Bjarni>Eddi|zuHause: I know that system and I don't like it
12:58<@Bjarni>basically it messes up even more when the system goes down and they have to rely on external signals
12:58<@Bjarni>or a train without a working reading of the "LZB" uses way more room on the tracks since it takes up more blocks
12:59<@Bjarni>but... why implement this in the game?
12:59<Eddi|zuHause>i'm speaking from a gameplay perspective, i don't think it will fit...
13:01-!-Frostregen [] has joined #openttd
13:07<Brianetta>Going home.
13:07-!-Brianetta [] has quit [Quit: Tschüß]
13:07<Tekky>Hmmmmm, when I think about it, I tend to favor distant signals to LZB-style control by Centralized Traffic Control. Distant signals give the player more feedback on what is going on.
13:08<Tekky>A player should be forced to also place distant signals, otherwise all trains are limited to a speed of 40km/h (=25mph)
13:09<Tekky>in order to always be able to brake in time.
13:09<@orudge>£396.03 so far
13:09<@orudge>not much more to go
13:09<Tekky>yay :)
13:11-!-fjb [] has left #openttd [Leaving.]
13:12<Tekky>However, I'm afraid that this means that signals will have to have many different aspects: red, green, caution level 1 (=reduce to 40km/h), caution level 2 (reduce to 70km/h), caution level 3 (reduce to 120km/h), caution level 4 (reduce to 180km/h), etc. Since Maglev trains can reach over 600km/h, I'm sure we will be needing at least 10 different aspects for distant signasl.
13:13<Tekky>signasl = signals.
13:14<Eddi|zuHause>Tekky: i don't think that is needed. the 600km/h train will just have to reserve like 10 signals ahead, if it can only reserve 9, it starts to slow down
13:14-!-lobster_MB [~michielbr@] has joined #openttd
13:14<Eddi|zuHause>slowing down can be done by a precalculated braking curve, like with stations...
13:17<Tekky>Eddi: What you suggest would only be possible if there are signals at regular intervals.....
13:18<Tekky>What if the only signal on the track is an entry signal for a station?
13:19<Tekky>Should the fast train be forced to slow down to 40km/h for the whole trip in order to be able to stop in time for a red signal?
13:19<Eddi|zuHause>no, it should run the red light, and cause crashes
13:20<Tekky>That is unrealistic.... if there next main signal has no distant signal, the previous main signal would signal a max speed of 40km/h.
13:21<Tekky>there = the
13:21<Eddi|zuHause>you as the track developer are in charge to put distant signals before the main signals
13:22<Eddi|zuHause>of course, switching off the "emergency brake" would be a difficulty option
13:22<Tekky>yes, I agree with that. But if he doesn't do that, he should be punished with slow speed (safety first!) instead of train crashes, imho.
13:23<Eddi|zuHause>Tekky: the train should check if there is a distant signal when reserving the track?
13:24<Eddi|zuHause>it might be possible...
13:24-!-fjb [] has joined #openttd
13:24-!-Yorick [] has joined #openttd
13:24<Tekky>the next main signal should know (cached information!) whether it has a distant signal. If not, then all reservations to this signal will have a speed limit of 40km/h.
13:25<Eddi|zuHause>Tekky: the main signal might be reachable from different distant signals
13:25-!-fjb [] has quit [Quit: Leaving.]
13:26-!-fjb [] has joined #openttd
13:26<Eddi|zuHause>Tekky: no, the train reserves tracks by tile (currently), and the reservation routine can have a flag if it passed a distant signal yet
13:27<Tekky>Eddi: Ah, yes, that must be taken into account.... therefore, this information whether a distant signal is present should be a track segment property instead of a signal property.
13:27-!-lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
13:29<Tekky>I don't think the train should have to keep track of this information, it should be cached in the track segment whether a distant signal is present.
13:30<Eddi|zuHause>not the train, the reservation routine... TryPathReserve()
13:31<Eddi|zuHause>it would then return a status info instead of a bool
13:32<Eddi|zuHause>this status struct would have a "slow" flag, which sets the speed limit to 40km/h
13:34-!-Fuco [] has joined #openttd
13:37<Tekky>I prefer to cache this information in the track segment, you know how much I like caching information. :-)
13:39-!-Brianetta [] has joined #openttd
13:46<Eddi|zuHause>yes, you can replace every (even implied) occurance of "track bit" by "track segment". but that does not change the fact that ultimately the train must know that it has a speed limit
13:46<Eddi|zuHause>it may pass a lot of track segments before getting to the one with the signal
13:47<Eddi|zuHause>the only alternative would be to store that in every reservation, so you add a "slow" reservation instead of a normal "use" reservation
13:48<Eddi|zuHause>you might want to consider if that would be more effort than storing it in the train
13:49-!-lobster_MB [~michielbr@] has joined #openttd
13:49<DJNekkid>could anyone see the last post on this thread?
13:49<@orudge>as in your post?
13:50-!-Roujin [] has quit [Ping timeout: 480 seconds]
13:51<DJNekkid>as in my post :)
13:52<@orudge>target exceeded!
13:52<@orudge>£494.30 :)
13:52<Wolf01>lol 1 day!!!
13:52<frosch123>"Allow all vehicle IDs from 0 to 255, exept 5F and 70, plus 256 and higher is also allowed" <- no, IDs (i*256 + 0x5F) is rejected for any i
13:52<@orudge>Wolf01: not even that
13:52<@orudge>21 hours :)
13:52<Brianetta>So, more RAM?
13:53<Brianetta>Beefier CPU?
13:53<Brianetta>What does a compile farm benefit from?
13:53<Wolf01>lots of GB to share p0rn and w4r3z!!!!
13:53<@Rubidium>Brianetta: beefier? The offer already has a quad core xeon ;)
13:54<Wolf01>masked of ottd savegames
13:54<@orudge>The plan is to get a server with a Quad Core Xeon X3210, 4GB DDR2, 2x500GB HD, 2TB bandwidth. The host who is offering to sponsor us is giving us a pretty good deal on it
13:54<Yorick>I think he won it
13:54<Yorick>and :)
13:54<Brianetta>Rubidium: More gigahurts
13:55<Yorick>already exceeded
13:55<@Rubidium>that'd cost much much more per month
13:55<@Rubidium>as in double the amount
13:55<Brianetta>Rubidium: CPU speed?
13:55<@Rubidium>cause you need to go to another "package"
13:55<Brianetta>This won't be your property, then?
13:56<@orudge>this one isn't
13:56<@orudge>we looked into a variety of options
13:56<Brianetta>I thought it'd be like my own colo
13:56<@orudge>including colocation (which the forums do)
13:56<Brianetta>where the kit ismine
13:56<Brianetta>I rent a slot ina rack
13:56<@orudge>but this is an offer that really beats what we could have done ourself
13:56<Brianetta>I suppose if it's leased then if parts go pop, they sort it out
13:57<Eddi|zuHause>2x500GB HD <- i assume that's Raid 1?
13:57<Eddi|zuHause>so 500 useable and 500 mirrored
13:58<Yorick>Eddi: no, the other way around :)
13:59<FauxFaux>XP in qemu doing VS builds, right?
13:59<@Rubidium>rather virtualbox as it's quicker
14:00-!-Mchl [] has quit []
14:01<@orudge>I won't have a proper fundraiser total for about a week or so, due to eCheque payments and bank transfers and paper cheque payments, but it'll be in excess of £500 it seems
14:01<@orudge>average donation was £9.51
14:01<@orudge>there were 52 in total
14:01<@orudge>31 of which were in euros
14:02<Fennec>that was fast.
14:02<@orudge>8 in US dollars
14:02<@orudge>and the rest in GBP
14:02<Sacro>why virtualbox
14:02<Sacro>why not mingw?
14:02<@orudge>mingw is what is currently used
14:02<@orudge>I'm not sure why virtualbox would want to be used, to be fair
14:02<Yorick>Sacro: current compilefarm crosscompiles :)
14:02<@orudge>but I assume there's a reason
14:02<Yorick>I'm not sure why VS would want to be used
14:03<@Rubidium>because we want to use the compile farm to make the release binaries too
14:03<Sacro>Rubidium: mingw can't do that?
14:03<@Rubidium>and mingw doesn't support win64 (or at least didn't very recently)
14:03<@Rubidium>Sacro: mingw's binaries can't make crash reports
14:03<@orudge>mmh, yes, I need to play with mingw-64 (well, the 64-bit version of mingw, it's not technically called that any more)
14:03<@orudge>Rubidium: does that rely on some sort of MSVC functionality?
14:03<@orudge>if so, what precisely?
14:04<@Rubidium>orudge: I've got absolutely no idea
14:04<@orudge>Rubidium: heh, fair enough
14:04<@Rubidium>I only know that it doesn't work for mingw and does work for MSVC
14:05<Sacro>can you not install the msvc compiler under wine?
14:05<@orudge>Older versions work on Wine I think
14:05<@orudge>but I don't think the 200x ones do
14:05<Sacro>orudge: not the IDE, the compiler
14:05<Sacro>not sure what it is called
14:05<@orudge>that is what I'm referring to
14:05<@orudge>according to somebody, .NET-type things make it break
14:05<@Rubidium>Sacro: the compiler requires .net 3.5, which fails to compile under wine
14:05<@orudge>but I've not tried it myself
14:06<@Rubidium>and mono doesn't support .net 3.5 enough to support msvc
14:06<Sacro>Rubidium: why does the compiler need .net 3.5 ><
14:06<@orudge>Ask Microsoft that one.
14:06-!-ecke [~ecke@] has quit [Quit: ecke]
14:06<@Rubidium>because it is fracking written (partly) in .NET
14:06<@orudge>we should port OpenTTD to Borland C++ or something exciting like that :D
14:07<@orudge>actually, I did try to build it with BCW back in the day
14:07<@orudge>back then, it would actually build
14:07<@orudge>these days, probably not
14:07<Sacro>orudge: qbasic
14:07*orudge wonders how Open Watcom is getting along
14:07<@Rubidium>go fix the DOS build, we NEED it ;)
14:07<@orudge>hmm, still v1.7a
14:07<@orudge>Rubidium: heh, maybe once I get other things done ;)
14:08<Sacro>surely yiou can run the vs2005 compiler on less
14:08<Sacro>it was before .net 3.5 came out
14:09<@peter1138>Pom te pom
14:09<@Rubidium>Sacro: 2005 needs .net 2.0, also doesn't work under wine nor mono as of a month ago
14:09<@Rubidium>it furthermore has problems with x64 when I last tried it
14:10<@Rubidium>crashes on the source code
14:10<@Rubidium>2003 doesn't understand enough of templates
14:10<Sacro>i don't see why mingw doesnt' do the job
14:10-!-Progman [] has quit [Remote host closed the connection]
14:10-!-ecke [~ecke@] has joined #openttd
14:11<@Rubidium>Sacro: because it doesn't have crash reports
14:11<Sacro>hmm, right
14:12<@Rubidium>which makes finding causes for bugs even harder
14:13<DJNekkid>thanx eddie :)
14:13<DJNekkid>and lakie :)
14:14<Yorick>get it crash reports :)
14:19-!-stillunk1own [] has joined #openttd
14:19-!-stillunknown [] has quit [Read error: Connection reset by peer]
14:20-!-ecke [~ecke@] has quit [Quit: ecke]
14:22-!-Lenny [] has joined #openttd
14:23-!-Lenny is now known as Guest1571
14:29-!-Guest1571 [] has quit [Quit: Bye for now!]
14:36-!-lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
14:45-!-mikl [] has joined #openttd
14:46<@Belugas>wow... fundraising seemed to be a real hit!
14:46<DJNekkid>we (L) OTTD :)
14:46-!-Powerek38 [] has joined #openttd
14:46<@Belugas>if there are any donators in this humble assembly, let me express my gratitude :D
14:47<@Belugas>thanks a lot
14:47<Sacro>orudge: you have overflowed
14:47<Prof_Frink>DJNekkid: Eat unicode! ♥
14:47<Powerek38>does anyone has a link to a download of the newcargos file?
14:47<Sacro>Powerek38: there are a fair few different newcargos
14:47*DJNekkid takes a big bite
14:48<Eddi|zuHause>Powerek38: that's a very old set, i recommend any of the various newer sets
14:48<Powerek38>Sacro: I've download the new industries set from pikka's Wiki and basically I'd like to have vehicles to carry those new products
14:48<Prof_Frink>DJNekkid: I wouldn't. ☠ It's poisonous.
14:49<Sacro>Powerek38: so you need a vehicles newgrf :p
14:49<Eddi|zuHause>Powerek38: then get the UKRS set from that same page
14:49<DJNekkid>or 2cc ;);)
14:49<Powerek38>Eddi|zuHause: thanks a lot :)
14:49<Eddi|zuHause>there also used to be a truck set, but that was not finished afaik
14:50<Powerek38>Eddi|zuHause: I don't mind, I prefer rail transport for cargo in OTTD :)
14:51*Yorick gets integrating xfire into openttd
14:52*orudge returns
14:53<Powerek38>great, it works, thanks a lot :)
14:53-!-Powerek38 [] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
14:53-!-ecke [~ecke@] has joined #openttd
14:54-!-Dred_furst [] has quit [Read error: Connection reset by peer]
14:56*Belugas wonders why Yorick is always trying that kind of stunts... nevertheless, have fun :)
14:57<@Belugas>now, that is a nice guy :) Powerek38... he did say "thanks" :D
14:57<Yorick>Belugas: it provides a nice sdk
14:57<@Belugas>and you think we will merge that patch in trunk? I don't think so...
14:57<@Belugas>not from me, at leat
14:58<Yorick>why not?
14:58<@Belugas>why so?
14:58*peter1138 ponders joystick control of vehicles!
14:58<@Belugas>and what to answer to the next who does the same thing?
14:58*Prof_Frink Ponder Stibbons.
14:59<Sacro>peter1138: again?
14:59<@Belugas>where is it going to stop?
14:59<Sacro>arstechnica reckon OOXML is dead
14:59<Yorick>"Why Use It: Drive Increased Friend Recommendations
14:59<Yorick>Xfire automatically detects over 600 games and game server IP addresses, with only moderate effort needed from the Xfire team to add each game to an Xfire .ini file. However, by default most games show very little data about what the player is doing. "
15:00<Yorick>"Xfire has already been proven to help drive sales of games by recommendations through the social network. When someone sees that 10 of their friends have all been racking up hours, they're almost certainly hitting their local game store on the way home. The Xfire SDK offers developers a way to increase the viral appeal of their game in our community. By providing rich, in-depth information...
15:00<Yorick>...about a user's current game stats, users will be more inclined to start up Xfire whenever they play in order to capture those statistics. Every time they use Xfire while they're playing, they're helping advertise your game to the 4,000,000+ member Xfire community."
15:00<Sacro>get it on steam
15:00<@Rubidium>blablabla... but there's no trail of the sdk on their website
15:01<@Rubidium>it's not even slightly cross platform
15:02<+glx>it's windows only, will never be in openttd
15:02<@Rubidium>so... all Windows devs are against it
15:03<Yorick>they added the support
15:03<@Belugas>poor Yorick...
15:03<@Belugas>we've already took a look at it in the past
15:03<Prof_Frink>Alsa poor Yorick, I knew him Oss.
15:03<@Belugas>as far as i can see, nothing has changed
15:08-!-TinoM [] has quit [Quit: Verlassend]
15:08-!-lobster_MB [~michielbr@] has joined #openttd
15:09<CIA-5>OpenTTD: rubidium * r14071 /trunk/src/video/win32_v.cpp: -Fix [FS#2057]: the screen wouldn't be centered on Windows multimonitor systems if the first monitor is right of the second one.
15:10<Fennec>Yorick: Xfire OpenTTD support? :P
15:15<Yorick>Fennec: Xfire supports openttd
15:18<@Belugas>XFire: openttd supports Yorick
15:18<Sacro>openttd: yoricks Xfire
15:19<Fennec>spiffy :)
15:19<Prof_Frink>supports: Xfire Yorick
15:20<Sacro>Euro Truck Simluator
15:24-!-Wezz6400 [] has joined #openttd
15:32<+glx>Sacro: it's not out yet
15:32<Sacro>glx: is on usenet
15:33<+glx> <-- point 4
15:33<Sacro>oh i know
15:33<+glx>it's out in germany though
15:33<Sacro>i don't see the pirates calling it a "demo"
15:33<Sacro>as a real pirate doesn't release demos
15:33<Sacro>that's just stupid
15:36<Sacro>the new version of grabit supports SSL but asks you if you want the port changing to 563 all the time
15:36<Sacro>and no longer supports >10 connections
15:37-!-Wezz6400 [] has quit [Quit: Wezz6400]
15:41-!-fonso [] has joined #openttd
15:45-!-Purno [] has quit [Read error: Connection reset by peer]
15:46<@peter1138>SCS Software...
15:46<@peter1138>Their other stuff was shit :(
15:49<ln>what else have they made?
15:52<Sacro>fair few truck driving games
15:52-!-stillunk1own [] has quit [Read error: Connection reset by peer]
15:53-!-stillunknown [] has joined #openttd
15:54<@peter1138>And the bus one.
15:56-!-LilDood [] has joined #openttd
16:02<ln>how do i add a restaurant car to a train
16:03-!-grumbel [] has joined #openttd
16:06<@peter1138>I don't think any set has one to add.
16:09-!-Farden123 [] has joined #openttd
16:15<Fennec>restraunt car? :) what does that do, in terms of game play?
16:15-!-lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
16:16<Fennec>maybe a certain number of them could reduce passenger value falloff over time....
16:16*Fennec shrugs.
16:16-!-Farden [] has quit [Ping timeout: 480 seconds]
16:17<frosch123>they load food, which vanishes until the destination is reached.
16:17<frosch123>though the weight of the train stays constant
16:21-!-Yorick [] has quit [Quit: Poef!]
16:21<Fennec>loading food sounds like a logistical PITA.
16:21<Prof_Frink>Fennec: Only loading flat breads.
16:23<Eddi|zuHause>ln: some consists in the DBSetXL have dining cars
16:28-!-fonso [] has left #openttd [Kopete 0.12.7 :]
16:29-!-Farden123 [] has quit [Ping timeout: 480 seconds]
16:39-!-Wezz6400 [] has joined #openttd
16:39<ln>are they economically useful?
16:39-!-Progman [] has joined #openttd
16:39<Eddi|zuHause>not really... they are normal long distance passenger coaches, only they pack less passengers
16:51<Eddi|zuHause>haha... "critical buffer overflow in µTorrent and BitTorrent. Solution for µTorrent: update. Solution for BitTorrent: switch to µTorrent."
16:57-!-Farden123 [] has joined #openttd
16:57-!-frosch123 [] has quit [Remote host closed the connection]
16:59<SpComb>can has url?
17:00-!-Ridayah_ [] has quit [Quit: The Rise and Fall of the Heavens themselves is dependant upon Humanity's belief and disbelief.]
17:01<Eddi|zuHause> <- it's in german
17:02*glx updates
17:03<Eddi|zuHause> <- from the links in the article
17:03-!-lobster_MB [~michielbr@] has joined #openttd
17:12-!-Guest1543 [] has left #openttd []
17:12-!-KillaloT [] has quit [Quit: Like's GUI? Then try HydraIRC -> <-]
17:14-!-ben_goodger [] has joined #openttd
17:16-!-Wezz6400_ [] has joined #openttd
17:16-!-Zealotus [] has quit [Read error: Connection reset by peer]
17:17-!-Zealotus [] has joined #openttd
17:19-!-Farden [] has joined #openttd
17:23-!-Wezz6400 [] has quit [Ping timeout: 480 seconds]
17:23-!-Guest1543 [] has joined #openttd
17:24-!-Farden123 [] has quit [Ping timeout: 480 seconds]
17:36-!-Guest1543 [] has quit [Quit: Guest1543]
17:37-!-david [] has joined #openttd
17:37-!-david is now known as Guest1591
17:40-!-a1270 [] has joined #openttd
17:41<@peter1138>Fortunately 'VS.NET' is nothing like HydraIRC, because HydraIRC is shit.
17:43<Prof_Frink>Surely your decision on which irc client to use should be made on the quality of that client.
17:43<Prof_Frink>Not some other random piece of software.
17:44<Prof_Frink>Like the taste of bananas? Try sausages!
17:44<@orudge>I choose to use mIRc because I like MS Paint!
17:45<Prof_Frink>orudge hates The Freedom.
17:47<Eddi|zuHause>i chose to use Konversation because i like KDE... was that wrong?
17:48<Prof_Frink>I use irssi because I like Konsole :)
17:49-!-Farden123 [] has joined #openttd
17:51<Fennec>hydraIRC is the spammiest-use-me-/quit-msg IRC client evar
17:51<+glx>KVirc works well enough for me
17:52<@peter1138>BitchX used to be, but hardly anyone uses that these days.
17:52*peter1138 > sleep
17:54-!-Farden [] has quit [Ping timeout: 480 seconds]
17:58-!-lobster_MB [~michielbr@] has quit [Quit: Leaving]
18:02-!-tokai|madspace [] has quit [Ping timeout: 480 seconds]
18:04-!-tokai|madspace [] has joined #openttd
18:04-!-jni [] has joined #openttd
18:19-!-DJNekkid [] has quit [Read error: Connection reset by peer]
18:20-!-divo [] has joined #openttd
18:23-!-fjb [] has quit [Quit: Leaving.]
18:25-!-dvo [] has joined #openttd
18:25-!-divo [] has quit [Read error: Connection reset by peer]
18:31*prakti uses irssi and that stands.
18:32*prakti is not one of those cruel guys who push around poor mouses all the time. ;-)
18:32<Prof_Frink>prakti: The how do you point at the appropriate xterm?
18:41-!-rortom [] has joined #openttd
18:42-!-LilDood [] has quit [Ping timeout: 480 seconds]
18:44-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:48<Eddi|zuHause>with the eye view camera, obviously ;)
18:50<ben_goodger>touché, kind sir
18:52<@Bjarni>I generally use a finger to point at objects
18:52<@Bjarni>either that or an object pointer
18:58-!-Brianetta [] has quit [Quit: Tschüß]
19:04-!-Farden123 [] has quit [Ping timeout: 480 seconds]
19:07-!-Yexo [] has quit [Ping timeout: 480 seconds]
19:08-!-Wezz6400_ [] has quit [Quit: brb]
19:27-!-Guest1591 [] has quit [Quit: Guest1591]
19:31-!-Dred_furst [] has joined #openttd
19:31-!-Dred_furst [] has quit []
19:36-!-fmauNeko is now known as fmauNekAway
19:36-!-Digitalfox [] has joined #openttd
19:42-!-fmauNekAway is now known as fmauNeko
19:48-!-welshdragon is now known as welshdra-gone
20:09-!-Progman [] has quit [Remote host closed the connection]
20:21-!-stillunknown [] has quit [Ping timeout: 480 seconds]
20:25-!-Brainstorm [] has quit [Ping timeout: 480 seconds]
20:26-!-rortom [] has quit []
20:27-!-dvo [] has quit [Read error: Connection reset by peer]
20:27-!-Golfgeo [~ice@] has quit [Quit: Booze is the answer. I don't remember the question.]
20:32-!-Eddi|zuHause [] has quit []
20:33-!-Eddi|zuHause [] has joined #openttd
20:39-!-Digitalfox [] has quit [Quit: Leaving]
20:44-!-prakti [] has quit [Read error: Network is unreachable]
20:47-!-prakti [] has joined #openttd
20:55-!-Tekky [] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
20:56-!-Frostregen [] has quit [Quit: und weg]
20:58-!-ecke [~ecke@] has quit [Quit: ecke]
21:02-!-KritiK [] has quit [Quit: Leaving]
21:06-!-Sacro [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has quit [Read error: Connection reset by peer]
21:09-!-Zorni [] has quit [Read error: Connection reset by peer]
21:09-!-bowman^2 [] has joined #openttd
21:15-!-Bjarni [] has quit [Quit: Leaving]
21:16-!-bowman [] has quit [Ping timeout: 480 seconds]
21:51-!-grumbel [] has quit [Quit: Client exiting]
22:11-!-welshdra-gone [] has quit [Quit: Leaving]
22:11-!-dlunch [~dlunch@] has joined #openttd
22:33-!-Fuco [] has quit [Quit: Quit]
22:50-!-glx [] has quit [Quit: bye]
22:56-!-fmauNeko is now known as fmauNekAway
23:01-!-elmex_ [] has joined #openttd
23:06-!-elmex [] has quit [Ping timeout: 480 seconds]
23:07-!-elmex_ is now known as elmex
---Logclosed Thu Aug 14 00:00:32 2008