Log for #openttd on 13th August 2008:
Times are UTC Toggle Colours
00:01:12  <SquireJames> Anyone?
00:08:33  <Tekky> Is this what you are looking for?
00:10:21  <Tekky> SquireJames: I have no experience with programming NewGRFs, but to me this sounds like the info you asked for.
00:14:15  <SquireJames> thats the one :)
00:16:01  *** welshdragon is now known as welshdra-gone
00:17:29  *** ob0t [] has quit [Read error: Connection reset by peer]
00:20:28  *** Wezz6400 [] has quit [Quit: reboot]
00:22:20  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
00:22:28  *** ob0t [] has joined #openttd
00:29:02  *** Wezz6400 [] has joined #openttd
00:29:03  <fmauNeko> legal question: the openttd logo is totally free ?
00:29:22  *** Dred_furst [] has quit [Quit: Leaving]
00:31:09  *** Sacro [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has quit [Read error: Connection reset by peer]
00:32:49  *** Eddi|zuHause [] has quit [Read error: Connection reset by peer]
00:33:12  *** Eddi|zuHause [] has joined #openttd
00:36:16  <Tekky> I guess it is..... or is the logo a modification of the original TTD logo? In that case, it is not free....
00:36:37  <Tekky> Either way, I don't think you will run into any trouble by using it.
00:37:26  <orudge> fundraiser 25% of the way to its target
00:38:28  <Tekky> nice :-) How much of the donation does Paypal keep when donating via PayPal?
00:39:21  <orudge> tends to be around 30p + between 3-5%, I think. eg, £10 becomes £9.46 or so.
00:40:07  <Tekky> ah, that's not bad.....
00:41:13  <Tekky> it used to be a big pain to send money into another country.... my Bank here in Germany charged so much for a bank transfer that it was not worth sending small amounts of money.
00:43:00  <orudge> mh
00:43:17  <orudge> I tend to receive a few bank transfers from abroad, and costs aren't so bad these days
00:43:18  <orudge> but PayPal etc is more convenient
00:43:19  <Tekky> Ah, you have 3 Paypal accounts, one for US$, one for GBP and one for EUR. That saves the charges for currency conversion.....
00:46:20  <Tekky> I'm afraid that it will take 3 days before I can donate, because I first have to send money from my bank account to my Paypal account. I'm afraid the fundraiser will be over by then, judging by the speed of the current fundraising....
00:47:55  <Tekky> Oh well, I guess I can just donate to the fundraising of the forums instead, then :-)
00:49:40  <fmauNeko> somebody has already tried tp
00:49:42  <fmauNeko> to*
00:49:57  <fmauNeko> use the ruby's UDPSocket to get game info ?
00:50:40  <orudge> Tekky: forum donations are very much appreciated. OpenTTD also accepts non-fundraiser donations, of course. :)
00:51:04  <Tekky> orudge: By the way, now that both TTDPatch and OpenTTD have support for PBS, I'm afraid that you will have to update all your complex track layouts on your web page :-)
00:52:21  <Tekky> Strangely, I haven't seen anyone ever post complex PBS track layouts ever......
00:52:53  <Tekky> I guess track layouts don't have to be complex anymore, now that we have PBS :-)
00:53:14  <orudge> Tekky: heh, well, I need to figure out YAPP, I did start a game the other week, but then YAPP was updated and my saved game broken. Haven't had time since...
00:53:24  <Ailure> wait
00:53:48  <Ailure> PBS support in openTTD?
00:53:48  <Tekky> orudge: You are aware that YAPP is now in trunk and that your savegames will therefore never break anymore?
00:54:13  <Tekky> Ailure: Yes, YAPP (Yet Another PBS Patch) is now officially in the latest nightly of OpenTTD.
00:54:32  <Ailure> the end is near then
00:54:49  <orudge> Tekky of course, yes
00:54:53  <orudge> I just haven't had time to play since ;0
00:54:57  <orudge> * ;)
00:55:08  <Tekky> Ailure: Hehe, you don't like PBS signals?
00:56:05  <Ailure> I admittly didn't care for them being implemented, but I don't have any dislike for them :p
00:56:30  <Belugas> Tekky, i think Ailure is pointing at the end ot TTDP
00:56:34  <Ailure> I just know that people have bugged about it for as long I been aware of openTTD, which I started to play back in the 0.3 days
00:56:37  <Belugas> altough i do not agree
00:56:53  * orudge watches House
00:57:07  <Ailure> no no
00:57:21  <Ailure> what I meant, it's one of those features that would "never" be implemented
00:57:22  <Ailure> ;)
00:57:52  <Belugas> oh... haaa... ok
00:57:54  <Belugas> well
00:58:27  <Ailure> Some people seem to be spiteful for openTTD stealing TTDpatch spotlight but ah well
00:58:38  *** Wezz6400 [] has quit [Quit: Zzz]
00:58:56  <Ailure> TTDPatch devolopment have slowed down from what I seen, which I find a shame too
00:58:59  <Tekky> Today I was surprised to find out that most of the functionality of YAPP has already been in TTDPatch for ages. The only missing feature was bi-directional stations, but also this functionality has been recently included into TTDPatch (called "through signals"):
00:59:22  *** grumbel [] has quit [Quit: Client exiting]
00:59:57  <Ailure> hmm
00:59:59  <Ailure> Intresting
01:00:20  <Ailure> Seems to be a less hackful way of implementing birectional stations
01:00:21  <Fuco> i think its just openttd developement seems to be much easier
01:00:36  <Ailure> I done a few bidirectional stations, but they usually involve having a dummy line for the signals
01:00:39  <Tekky> with bi-directional stations I mean bi-directional pass through (non-terminus) stations
01:01:08  <Tekky> Ailure: yes, such dummy lines are no longer necessary with TTDPatch through signals and in YAPP (OpenTTD)
01:01:27  <Ailure> ah
01:01:46  <Ailure> I never found bidrectional stations too effecient, and only do them for the looks and when I want to break out of the ro-ro/terminus mold
01:02:09  <Tekky> well, they are very efficient now, with PBS :-)
01:03:09  <Belugas> Fuco, i wold say that it's easier when a lot of people are helping
01:03:40  <Fuco> well, i've heard that ttdp is basicaly assembly(?), while ottd is c++
01:03:40  <Belugas> ttdp guys have quite a limited coders pool.
01:03:50  <Belugas> language does not matter
01:04:16  <Belugas> ttpd does have parts written in C too
01:04:17  <Fuco> oh it does.. asm vs c++ .. its LOT easier to do a c++ patches and stuff
01:04:22  <Fuco> also, more ppl knows that
01:04:25  <Fuco> know*
01:04:51  <Tekky> The only thing that you can't do (yet) with PBS is implement priority lines such as these:
01:04:52  <Fuco> i've just heard, i don't know much about developement of either one
01:05:05  <Belugas> no, language does not matter.  what matters is how well you know the code yo are working on
01:05:30  <Belugas> and TTD is quite a beast to handle
01:05:30  <Fuco> yea well
01:05:46  <Belugas> true, open starts to get easier to work with
01:05:51  <Fennec> Language /can/ matter. It's just seldom the most important thing.
01:05:58  <Belugas> but that doe snot say it's easier than asm
01:06:19  <Tekky> For such priority lines, you do need presignals and not PBS signals. However, I consider such priority lines an ugly hack. I hope that OpenTTD will soon offer a better possibility for implementing train priorities.... There have already been several suggestions on how to do this.
01:06:38  <Fuco> well, ttdp was RE-ed from original?
01:06:46  <Belugas> no
01:06:51  <Belugas> it sits on top of it
01:06:54  <Fuco> ah
01:06:58  <Belugas> you do need the original exe
01:07:06  <Belugas> it is really a patch
01:07:07  <Fuco> so it's really a patch
01:07:08  <Fuco> ;)
01:07:15  <Belugas> hehe
01:07:16  <Belugas> ueah
01:07:21  <Fuco> and ottd was done from scratch?
01:07:27  <Belugas> nope
01:07:43  <Tekky> it was decompiled into C, as far as I know.
01:07:48  <Belugas> it is from a de-assembly of the origina;
01:07:50  <Belugas> l
01:08:00  <Belugas> and reconstructed in c,
01:08:14  <Fuco> ah
01:08:17  <Belugas> and in c++ relatively shortly
01:08:26  <Fuco> yea, but its "quite" similar
01:08:52  <Fuco> at least, making c routines into c++ isn't that hard
01:09:05  *** divo [] has quit [Read error: Connection reset by peer]
01:09:16  *** divo [] has joined #openttd
01:09:28  <Belugas> indeed not
01:09:54  <Belugas> it's more about taking advantages of the features of c++
01:10:02  <Fuco> yea
01:10:18  <Fennec> C++ would make some sense for OpenTTD but it wasn't done so ho hum ah well. :)
01:10:35  <Belugas> hum?
01:10:38  <Fennec> -- or was it? *thinks it's plain C*
01:10:53  * Fennec -- never paid THAT much attention silly me could be wrong
01:10:57  <Lakie> I think Open is C++
01:11:09  <Fuco> don't make me download the source! :D
01:11:16  <Lakie> Most of it is not OOP however if thats what you were getting at?
01:11:21  <Belugas> open is C with a growing flavor of C++
01:11:31  <Belugas> hey Lakie :)
01:11:36  <Lakie> Hi Belugas. :)
01:11:47  <Belugas> it does not need to be OOP all the way
01:12:00  <Belugas> if it does not serve a purpose, it's silly to change just for changing
01:12:02  <Tekky> I'm currently studying YAPF which makes heavy use of C++ templates, which I find very heard to understand :-(
01:12:03  <Lakie> Indeed, some things are quite fine as they are.
01:12:09  * Belugas nods
01:12:15  <Tekky> heard = hard
01:12:15  <Lakie> Templates are fun
01:12:20  <Fuco> yea, i've never understood that
01:12:22  <Fuco> templates
01:12:34  <Belugas> i'm starting to myself
01:12:38  <Belugas> not easy
01:12:43  <Lakie> Hmm?
01:12:55  <Belugas> templates
01:13:01  * Lakie found generics and templates fairly simple to understand writing good ones no so good.
01:13:36  <Belugas> mmh... compiling in release takes AGES
01:13:37  <Lakie> The concept is using a generic set of code which you then set the type for later
01:13:42  <Lakie> Hehe
01:13:51  <Belugas> what do you call "generic" ?
01:13:55  <Lakie> Ah
01:13:58  <Fennec> Vehicles could be done in a decently OOish way.
01:14:02  <Lakie> Its the C# equvilent sorry.
01:15:13  <Belugas> ok
01:15:24  <Tekky> I plan to merge the YAPF cache and the PBS reservation mechanism, to make PBS reservations more efficient. But I still haven't understood the YAPF template code :-(
01:15:31  <Belugas> Fennec, do you think they are not already oop'ed?
01:15:51  <Belugas> Tekky, take all your time and do it right :)
01:16:10  <Fennec> mm, there's mild OO and then there's serious OO :)
01:16:17  * Fennec should look some time.
01:16:18  <Fuco> ah the silly pathfinders.. :P
01:16:21  <Tekky> Belugas: I'll try :)
01:16:44  <Fuco> lots of graph theory i assume
01:17:49  <Belugas> Fennec, sorry to be rude, but: it's easy to critisize something.  it's another to propose alernative
01:17:58  <Fennec> sorry
01:17:59  <Belugas> plus, once again, change for change is stupid
01:18:02  <Fennec> I'm not trying to be critical
01:18:20  <Fennec> I'm sure it's all fine. :)
01:18:24  <Belugas> change for a purpose is acceptable
01:18:38  <Lakie> It does not need to be poor OOP, I believe in some changes making it OOP would actually slow it down.
01:18:58  <Lakie> (Because of the extra time creating, destroying and handling objects).
01:19:00  * Lakie hides
01:19:10  * Belugas agrees with Lakie
01:19:45  <Fuco> Lakie, its all about how you design it
01:19:56  <Fuco> might me a bit slower, but who cares about speed nowadays
01:20:05  <Fennec> #openttdcoop does :P
01:20:10  <Fuco> heh ;d
01:20:12  <Tekky> Fuco: I disagree with the last satement of Fuco :)
01:20:18  <Fennec> when they put 800 trains in a game :P
01:20:21  *** divo [] has quit [Read error: Connection reset by peer]
01:20:28  <Tekky> yes, for example if you do that :)
01:21:14  <Fuco> we can be glad ottd is not full 3d then :D
01:21:42  <Lakie> OpenTTD would not work well in full 3d.
01:21:46  <Fuco> but anyway, thats for the GPU, so it wouldn't be such different
01:21:55  <Lakie> Very few games have full 3d with the same sort of view
01:22:08  <Fuco> i like the graphics as they are
01:22:11  <Fuco> oldschool
01:22:16  <Fuco> nice and clear
01:22:19  <Fennec> ok ppl just one moment AGAIN FOR CLARIFICATION by my earlier statement I was attempting to expose a rationale for being OO with a program like OpenTTD and NOT SAYING that OpenTTD's handling of vehicles is in any way suboptimal!!!!
01:22:21  <Lakie> 8bbp project looks ace.
01:22:23  <Fennec> sorry. :(
01:22:40  <Belugas> [21:20] <Fuco> might me a bit slower, but who cares about speed nowadays  <-  we do ;0
01:22:50  <Fuco> ah stop blaming me
01:22:50  <Fuco> :D
01:23:05  <Fuco> it was only an ironical statement... when you look at some new games
01:23:24  <Fuco> optimalisation is truely "unknown" therm today
01:23:46  <Fuco> crysis or supreme comander comes in my mind
01:23:57  <Belugas> it's ok, Fennec :)
01:24:19  <Lakie> Its true that game designers don't optimise as much as in the past, Fuco
01:24:29  <Lakie> But they are optimised over just raw.
01:24:35  <Fuco> yea, back in the 386 times
01:24:36  <Fuco> :D
01:24:47  <Lakie> Heh
01:24:50  <Fennec> that /seemed/ to be a momentarily relevant point of conversation. anywho.
01:24:53  <Belugas> they tend to rely on compilers to do the job, i tik
01:24:59  <Belugas> think
01:25:11  <Fennec> today you want to do /smart/ optimizations
01:25:12  <Lakie> Probably, but compilers won't fix poor code for them.
01:25:14  * Lakie hides
01:25:16  <Fennec> which means profiling to see where the Slow is
01:25:20  <Belugas> indeed not :)
01:25:21  <Fennec> and fixing /that/
01:25:34  <Belugas> SmatZ does a very good job at that
01:25:40  <Belugas> so does Rubidium
01:25:45  <Tekky> It would be nice to seperate the graphics rendering from the rest of the game engine, so that the graphics renderer could easily be interchanged with a 3D graphics renderer..... However, I'm afraid that this would be a lot of work :-(
01:25:47  <Fennec> rather than trying to shave off microseconds from a call that happens twice by hacking it to pieces.
01:26:03  <Belugas> but then, Rubidium does a good job at ...well... the whole stuff...
01:26:04  <Fennec> Tekky: indubitably!
01:26:09  <Fennec> Tekky: most worthwhile stuffs is :)
01:26:10  <Fuco> Tekky, i was thinking about that yesterday :D
01:26:22  <Fennec> Tekky: that, or "already done"
01:26:24  <Fuco> kinda like linux
01:26:32  <Fennec> Tekky: or possibly "we didn't think of that" but anyway :)
01:26:47  <Fuco> core and graphics are independent
01:27:09  <Belugas> not in ottd, they are quite intertwined
01:27:19  <Belugas> well.. in TTD in general
01:27:26  <Tekky> I think it would be great to have 3D graphics with a rotatable camera for high-end machines, but keep the old graphics for low-end machines.
01:27:35  <Belugas> and a 3d renderer?  forget that :)
01:28:03  <Fuco> it wouldn't be the good olt tt anymore.. with all the fancy 3d graphics
01:28:20  <Belugas> indeed not
01:28:37  <Tekky> who said the 3D graphics would be fancy? :-) I was thinking of 3D graphics without textures, as a start. :-)
01:28:48  <Fuco> and i cant imagine how curves should be handled
01:28:57  <Fuco> imagine 2*45 in 3d.. bleh
01:29:15  <Tekky> I'd simply draw the engine of a train as a red box and the carriages of the train as black boxes :-)
01:29:25  <Fuco> :P
01:29:42  <Fuco> btw, ottd is now opengl rendered?
01:29:50  <Tekky> and the houses would also be boxes :-) Well, cubes to be exact.
01:30:17  <Tekky> no, it uses DirectDraw with Win32 and SDL with all other platforms.
01:31:21  <Fuco> some day we may see it in 3d.. that will atract even more ppl to play the game
01:31:38  <Fuco> coz the game is awesome
01:31:48  <Fuco> i mean all the "engine"
01:31:55  <Fuco> but the graphics are sort of old
01:32:09  <Tekky> There have been efforts to make a 3D Clone of OpenTTD and several forums have been created for this project:
01:32:16  <Tekky> But I'm afraid this project has dies :-(
01:32:20  <Fuco> transport empire?
01:32:22  <Tekky> dies = died
01:32:25  <Fuco> i've heard about it
01:32:31  <Tekky> yes, Transport Empire.
01:32:32  <Belugas> can you imagine defining all the 3ds of all the obecjts of the game?  would be an enormous job
01:32:42  <Fuco> yea
01:32:46  <Fuco> thats the hard part
01:32:50  <Belugas> there are other games of trians that are 3d
01:32:52  <Fuco> eats lots of time
01:33:00  <Fuco> and not worth at all
01:33:01  <Tekky> Belugas: As I said, I would use untextured boxes as a start :-)
01:34:37  <Belugas> there is nothing stoping you to even start right now, Tekky.  DOing a fork of OpenTTD is permitted :)
01:34:40  <Fuco> remaking all gfrs into 3d boxes will take some time too :P
01:34:52  <Belugas> tell that to Zephiris ;)
01:35:15  <Tekky> But I think the best solution would be to try to seperate the graphics rendering in OpenTTD from the rest of the game engine. This would allow the graphics rendering to be interchanged with a 3D renderer, but it would also OpenTTD to use dual-core processors: One core for the graphics, one core for the game engine....
01:35:49  <Belugas> no no no no no no no!@!!!!
01:35:57  <Belugas> you do that, you're dead!
01:36:01  <Fennec> hm?
01:36:08  <Tekky> lol, why that? :)
01:36:14  <Belugas> you will simply need to rewrite the whole system
01:36:26  <Fennec> oh, that's all? :)
01:36:27  <Lakie> It'd have to be very optimised to show say a busy town....
01:36:48  <Belugas> the two are too intertwined to be easily separated
01:36:56  <Tekky> is the graphics really so tightly interwoven with the game engine that a complete rewrite is necessary?
01:37:20  <Tekky> hmmmm.....
01:37:31  <Belugas> why do you thiunk i've saoid that?  becasue that converstation has been gong on for ages
01:37:44  <Belugas> you are not the only ones who came up witht hat idea
01:38:25  <Fuco> let us at least dream about it! :D
01:38:27  <Lakie> Its been suggested a great many times I'm sure
01:38:40  <Fennec> I'm sure it's technically quite difficult but is there anything fundamentally wrong with it on its own merits?
01:38:50  <Belugas> yes, Lakie, and the counter has just been incremented ;)
01:38:57  <Lakie> Hehehe
01:39:41  <Belugas> Fennec, everything can be done, it's just that the time needd to do it and to battle the bugs that will surface are really not worth the efforts
01:39:58  <Belugas> plus, you need to have quite a good battle plan before even starting to code
01:40:07  * Fennec mmmms.
01:40:23  <Belugas> it's nothing more than a rewrite, i'm telling you
01:40:27  <Fuco> yea, well designed plan is first step to success
01:40:39  <Fuco> i was once making a game
01:40:41  <Tekky> well, starting a completely new game, such as Transport Empire, is certainly more work than seperating the game engine from the graphics rendering, I guess.....
01:40:44  <Fuco> without any planning
01:40:49  <Fuco> it was a mess after a week
01:40:51  <Fuco> ;D
01:40:55  <Belugas> so for a plan, yo have to know what yo're going to attack, so it means a very good knwoledge
01:41:39  <Belugas> Tekky, wrong, it's worse.  a new game, you have all the freedom for you.
01:41:40  <Tekky> Belugas: Are you saying that files such as rail_cmd.cpp would also have to be rewritten?
01:41:41  <Fennec> Belugas: Comment, if you will, on the approximate feasibility of this simplistic. "Spawn two processes. One acts as a server and you hack out all the calls to draw things. One just connects to it as a multiplayer thingy."
01:41:41  <Fuco> Tekky, neccessarily
01:41:44  <Fuco> not*
01:42:25  <Fuco> with a new poject, you can make things much easier for further developement
01:42:33  <Fuco> while with the old code, you have to "stick with it"
01:42:39  <Belugas> Tekky, it's not a per file base process, it's a per concept one
01:43:00  <Belugas> Fennec, i do not understand your requeest
01:43:19  <Fennec> Belugas: as a plan to decouple rendering and engine-ing.
01:43:41  <Fennec> is it not feasible at all? remotely feasible? trivially feasible? somewhere in between? :P
01:43:42  <Tekky> Belugas: Does OpenTTD currently draw directly to the screen, without using a back buffer?
01:44:20  <Fuco> there should be double buffering
01:45:13  <Belugas> Fennec: in the case of open, hardly feasible
01:45:27  <Fuco> what does feasible means? available?
01:45:32  <Fuco> mean*
01:45:37  <Fennec> able to be accomplished
01:45:42  <Fuco> thx
01:45:45  <Fennec> more or less
01:45:50  <Belugas> Tekky, i do not know the internals of the blitters
01:45:54  <Fennec> able to be accomplished within reasonable parameters
01:46:18  <Belugas> but i know it does not directly to the screen
01:46:20  <Fennec> Are there logical dependencies of the backend engine on the graphics code?
01:46:35  <Belugas> not that i know of
01:46:54  <Belugas> in the sens htat code does not address a specific card type
01:48:51  <Fennec> I mean, could a headless server be made? one that doesn't try to open any graphics buffers or anything at all?
01:49:11  <CIA-5> OpenTTD: belugas * r14059 /trunk/src/news_type.h: -Fix(r13872): Wrong comments in enum. Dear old copy/paste...
01:49:36  <Belugas> like dedicated server?
01:49:52  <Fennec> is that headless? :)
01:50:57  <Fennec> if so just run one "server" process and one "frontend" process and turn the single-player mode into a one-player-only version multiplayer mode. Or something stands in the way? :)
01:51:06  * Fennec shrugs. You all know muuuuuch better than I.
01:53:39  <Belugas> if only i could answer that in an intelligent way...
01:55:50  <Fuco> oh crap, its 4 am.. i should go sleep :P
01:56:26  <Fuco> at least i have a free day tomorrow(today:D)
01:56:47  <Fuco> good night guys
01:56:59  <Tekky> good night, Fuco
01:57:01  *** Frostregen_ [] has joined #openttd
01:57:18  *** Fuco [] has quit [Quit: Quit]
01:57:26  <Tekky> I've just taken a look at the code and the drawing code really is tightly interwoven with the game engine :(
01:58:11  <Lakie> Belugas: am I the only one who gets a trunk build error on line 102 of console_gui.cpp?
01:58:43  <Lakie> VSC++ 2008...
01:59:11  * Belugas goes checking
01:59:39  <Belugas> wouild help to actually updates...
02:00:53  <Belugas> compliling
02:00:57  *** jni [] has joined #openttd
02:02:41  *** Frostregen [] has quit [Ping timeout: 480 seconds]
02:02:42  *** Frostregen_ is now known as Frostregen
02:04:22  *** stillunk1own [] has quit [Ping timeout: 480 seconds]
02:07:36  *** fmauNeko [] has quit [Ping timeout: 480 seconds]
02:08:21  <Belugas> confirmed, Lakie
02:08:27  <Belugas> working on it
02:08:50  <Tekky> oh well, the drawing code does not seem that tightly interwoven, after looking at it more carefully.....
02:09:05  *** jni [] has quit [Ping timeout: 480 seconds]
02:09:06  *** KritiK [] has quit [Ping timeout: 480 seconds]
02:09:16  <Lakie> Well, the drawing and sprite storage would have to be split off first?
02:09:17  <Tekky> maybe I can seperate the drawing code from the game engine, even if Belugas will kill me for it. :-)
02:10:39  <Tekky> I think the sprite storage belongs to the drawing code, I see no reason to seperate them.....
02:11:06  <Fennec> A number of games run single-player as an instance of dedicated multiplayer like that. FreeCiv comes to mind. Stars! is another.
02:11:13  <Tekky> ah, you mean seperate drawing and sprite storage code from the game engine?
02:11:51  <Fennec> I mean, they have a "dedicated server", and they have a client that connects to that dedicated server, and that's single-player mode for ya.
02:11:58  <Lakie> Well, if you replace it with 3d models you'll have to sotre them somewhere!
02:12:47  <Belugas> "typeof" seems to be the problem...
02:14:13  <Tekky> Lakie: yes, but the 3D drawing code will be very different from the 2D drawing code, too... Therefore, I see no point in seperating the drawing code from the sprite/model storage.
02:14:44  <Lakie> I merely meant you may have to alter how its all stored
02:15:39  *** fmauNeko [] has joined #openttd
02:17:00  <Tekky> yes, I plan to separate the game engine from the sprite storage/drawing code. I will then leave the game engine intact and add my own 3D drawing code and 3D model storage, which can be used instead of the existing 2D drawing code/sprite storage.
02:17:26  <Lakie> Night.
02:17:39  <Tekky> However, I will only make colored cubes in my 3D models and leave it up to other people to make proper 3D models :)
02:17:46  <Tekky> good night, Lakie.
02:17:47  <Fennec> haha.
02:17:51  <Lakie> Good luck with fixing the bug, Belugas. :)
02:17:57  <Belugas> thnaks
02:18:06  <Belugas> may be a typo
02:18:23  <Lakie> Those are the most annoy bugs...
02:18:42  <Belugas> yup
02:18:51  <Belugas> even more when the "owner" is sleeping :)
02:19:11  <Lakie> hehe
02:21:34  <Tekky> oh oh, I just encountered a problem..... I wanted one CPU core to do the graphics rendering of the viewport and the other core to handle the actual game engine...... but the graphics rendering also requires access to the map array while rendering the viewport, so the other CPU core is not allowed to change the map array until graphics rendering has finished. This makes dual-core useless :-(
02:21:36  <Belugas> nope, not a typo
02:21:53  <Belugas> heheh
02:22:06  <Tekky> Well, I guess I can just copy the map array for the region of the viewport......
02:22:14  <Belugas> Tekky, i'm proud of yhou, you found out quite fast :)
02:22:58  <Tekky> the viewport area of the map is normally a lot smaller than the total map size, so it should be easy to copy that area of the map into an external memory buffer.
02:24:05  <Tekky> so I guess I will just copy the map area of the current viewport to an external memory buffer after the game engine has completed calculations for the current tick, after that both CPU cores can do their work.
02:25:16  <Tekky> hehe, I don't give up so fast :)
02:26:43  <Tekky> Belugas, do you have any idea what percentage of CPU resources are taken up by graphics rendering? If it is only a few percent, maybe it is not worth making the code support dual-core CPU by splitting game engine and drawing code?
02:27:14  <Belugas> and make it so that the map accessors are redirected to the new copy? mmh... sonds quite a challenge.  don't give up!
02:27:43  <Belugas> i cannot answert the question
02:28:03  <Belugas> but bear inmimnd it will only apply to those who have dual core.
02:28:08  <Belugas> not eveyone does
02:28:23  <Belugas> so in fact, you'll slow them down, including some devs
02:28:58  <Belugas> and i guess the drawing is traking quite a good percent of the cpu usage
02:29:06  <Belugas> altough do not take my words for it
02:29:23  <Tekky> hehe, yes, it will be a bit of work to make a second set of map accessors :)
02:30:53  <Tekky> oh, I just noticed that there can be more than one viewport :-( OpenTTD allows for several viewports, for example you can follow several trains at once :-(
02:31:03  <Fennec> mmm :)
02:31:08  <Fennec> an excellent feature.
02:31:38  <Fennec> how big is the map? is it feasible to do a bulk copy of the whole thing? :)
02:32:30  <Fennec> then maybe you could fake out the data pointers in one process, to point to different structures...
02:32:34  <Tekky> well, a 4096*4096 map has 16386 tiles.
02:32:43  <Fennec> how much a tile?
02:34:45  <Belugas> 9 bytes, if i'mnot mistaken
02:34:47  <Tekky> as far as I can tell, it's 7 bytes per tile....
02:35:07  <Tekky> m1, m3, m4, m5, m6 seem to take one byte and m2 takes 2 bytes, so total is 7 bytes.
02:35:51  <Fennec> 112 megabytes, memory to memory copy? hmm.
02:36:01  <Tekky> an, the height is stored too, so total 8 bytes per tile.
02:36:13  <Tekky> an = ah
02:36:15  <Fennec> 144 if it's 9 bytes, 128 if 8
02:36:15  <Belugas> 	uint16 m2;
02:36:46  <Tekky> struct Tile {
02:36:47  <Tekky> 	byte type_height; ///< The type (bits 4..7) and height of the northern corner
02:36:49  <Tekky> 	byte m1;   ///< Primarily used for ownership information
02:36:50  <Tekky> 	uint16 m2; ///< Primarily used for indices to towns, industries and stations
02:36:52  <Tekky> 	byte m3;   ///< General purpose
02:36:53  <Tekky> 	byte m4;   ///< General purpose
02:36:55  <Tekky> 	byte m5;   ///< General purpose
02:36:56  <Tekky> 	byte m6;   ///< Primarily used for bridges and rainforest/desert
02:36:58  <Tekky> };
02:37:10  <Belugas> 8 bytes so far
02:37:19  <Belugas> struct TileExtended {
02:37:19  <Belugas> 	byte m7; ///< Primarily used for newgrf support
02:37:19  <Belugas> };
02:37:23  <Belugas> and 9
02:37:49  <Fennec> byte alignment?
02:37:58  <Belugas> can say that
02:38:05  <Belugas> more - ease of access
02:38:26  <Belugas> and result of countless dicussions...
02:38:30  <Fennec> I mean, are the structures aligned on 8-bit boundaries, 16-bit, 32-bit, what?
02:38:42  <Fennec> nm that's probably compiler-dependant
02:39:19  <Tekky> 32-bit members are normally aligned on 32-bit boundaries, I think, and 16-bit members are aligned on 16-bit boundaries. But this is the case in the above struct.
02:39:48  <Tekky> There are no 32-bit members and the only 16-bit member is already aligned.
02:40:45  *** Guest1402 [] has quit [Quit: Guest1402]
02:40:56  <Tekky> so, a 4096*4096 map takes about 150KiB.
02:41:45  <Tekky> no, sorry, 160 MiB
02:42:50  <Fennec> go benchmark a memcpy() on a 160 MiB data block. ;)
02:43:00  <Tekky> and copying 160MiB every tick (which is about 60 times per second) is a bit much.....
02:44:43  <Belugas> but hey... how cares... it's on dual core heheh
02:44:54  <Belugas> how -> who
02:45:15  <Tekky> hehe, well, the code should also run well on single core :)
02:46:02  <Tekky> so only the map data of all viewports should be copied every tick and not the whole map.
02:47:09  <Belugas> and map accessors easily pointed to the appropriate map saved :)
02:47:12  <Tekky> computers with HyperThreading will also profit from this seperation.
02:47:30  <Fennec> so you keep a map structure with the same layout, and just let XYZ portion of it get updated, and hack out some pointers so the new code looks at the new data store?
02:50:10  * Belugas retires to bed. enjoy the conversation
02:50:39  <Tekky> Yes to the first two portions of your question. About the last part: I am not sure what pointers there are. I must look exactly how trains and other vehicles are linked to the map
02:50:40  <Fennec> the disadvantage is OMG MEMORY BLOAT ;)
02:50:42  <Tekky> good night Belugas.
02:51:08  <Tekky> Fennec: No, the viewport area is much smaller than the total map area.
02:51:27  <CIA-5> OpenTTD: belugas * r14060 /trunk/src/genworld_gui.cpp:
02:51:27  <CIA-5> OpenTTD: -Codechange: Replace numbers with Colours enum on Gen world gui.
02:51:27  <CIA-5> OpenTTD: Note that some WWT_TEXT widgets have received a COLOUR_x value.
02:51:27  <CIA-5> OpenTTD: It is not a valid colour a per say. THe strings been displayed there do have their own colours encoded.
02:51:27  <CIA-5> OpenTTD: IT is currently just for the sake of ease of writing, as TextColour and Colours are not really related.
02:51:46  * Fennec was describing the trivial implementation case (copy the entire layout and just update the parts as necessary)
02:53:28  <Tekky> if you copy the enitre map as is, then the coordinates of the vehicles do not have to be updated for the new map. I don't think that vehicles use pointers to reference the map, they only store coordinates of the map tile.
02:57:50  <Frostregen> for the viewport only thing: consider zoomout
02:58:19  <Tekky> oh.. I didn't think of that :)
03:00:42  <Fennec> consider 3d zoomout. ;)
03:01:02  <Fennec> zoom out at an angle when the ground is practically flat ;)
03:03:09  *** elmex_ [] has joined #openttd
03:04:39  <Tekky> oh, hehe, that wouldn't be nice :)
03:05:01  <Fennec> then benchmark your 160-meg memcpy again :P
03:06:19  <Suisse> ^^'
03:07:43  *** elmex [] has quit [Ping timeout: 480 seconds]
03:08:06  *** elmex_ is now known as elmex
03:08:32  <Tekky> hehe, yes, that is a serious problem.....
03:09:27  <Fennec> bulk memcpy may be faster than trying to compute exact chunks and be selective
03:12:39  <Frostregen> maybe you could just multithread the drawing commands? main thread still calls tile->draw, but the command is just enqueued into a draw-command-queue, which will be carried out (actual blitting) by the second thread?
03:14:13  <Tekky> yes, that would be possible...... I'm not sure what percentage of the CPU resources the blitting itself takes, though.
03:14:24  *** fmauNeko is now known as fmauNekAway
03:14:29  <Frostregen> i don't know too
03:15:12  <Frostregen> maybe some profiling would be a good start
03:15:20  <Frostregen> to see if the effort is worth it
03:17:18  *** HaloMaster [] has joined #openttd
03:17:26  <Tekky> hmmmm...., the draw-command queue you suggest will also be many megabytes big, if you zoom out very far.......
03:17:45  <Frostregen> depends on how fast it will be emptied ;)
03:18:45  <Frostregen> you could fix its size, and block the main thread if the queue is full
03:19:40  <Tekky> well, one CPU core will be blitting the previously computed game state while the other CPU core is computing the game state of the next tick. So, ideally, the draw-command-queue would only be emptied once per tick...
03:19:42  <Frostregen> but i have no idea, what info would need to be queued
03:19:59  <Frostregen> (just x/y/sprite?)
03:20:46  <Tekky> You also need depth information, I think....
03:20:54  <Tekky> and a second sprite, a palette sprite.....
03:21:24  <Tekky> therefore, I'm afraid your draw-command-queue will contain a similar amount of information as the map array itself....
03:21:25  <Frostregen> not all sprites have depth
03:21:52  <Tekky> that just means they have a depth value of 0 :)
03:22:12  <Frostregen> nope, they are drawn immediately
03:22:15  <Tekky> void AddSortableSpriteToDraw(SpriteID image, SpriteID pal, int x, int y, int w, int h, int dz, int z, bool transparent, int bb_offset_x, int bb_offset_y, int bb_offset_z, const SubSprite *sub)
03:22:39  <Frostregen> those ^^ are drawn later
03:22:46  <Frostregen> (iirc)
03:23:18  <Frostregen> they are stored in some list anyway
03:23:23  <Tekky> you currently need a SpriteID of the sprite to draw, a SpriteID of the palette, then the x and y coordinate, and then additional depth information. The rest I don't understand, but you have default values for the rest, anyway, as shown here:
03:23:28  *** HaloMaster is now known as Crabman
03:23:46  <Tekky> void AddSortableSpriteToDraw(SpriteID image, SpriteID pal, int x, int y, int w, int h, int dz, int z, bool transparent = false, int bb_offset_x = 0, int bb_offset_y = 0, int bb_offset_z = 0, const SubSprite *sub = NULL);
03:24:24  <Frostregen> i think those sprites will be added to a list, and are drawn at the end
03:24:38  <Frostregen> this list just has to be passed to the second thread
03:24:51  <Frostregen> (which could do the sorting too)
03:25:02  <Tekky> hmmmm.....
03:25:47  <Tekky> I think I need to analyze the current situation more before I decide what I want to change.....
03:26:02  <Frostregen> ;)
03:26:39  <Tekky> if it is true that they are sorted now anyway, then this list must be about a megabyte long when you zoom out fully with the current 2D client.....
03:26:51  <Frostregen> sure :)
03:29:45  <Frostregen> ParentSpriteToDraw *ps = _vd.parent_sprites_to_draw.Append();
03:30:00  <Frostregen> looks like some add to a list
03:31:37  <Tekky> yes, I think so, too......
03:32:42  <Tekky> this list cannot be processed before the tick's final game state is calculated, though. This is because the sprites must be sorted before they are blitted.
03:33:48  <Frostregen> this could be ok. the second thread could be still busy blitting the immediate-draws. after that he sorts the list, and draws those
03:34:55  <Frostregen> first the new queue for immediate draws, afterwards the old sorted-sprite list.
03:37:52  <Tekky> yes, possible....
03:40:38  <Tekky> I must think about this at a time when I am less tired :) It is 6 AM here in Germany :)
03:41:41  <Frostregen> ich weiss ;)
03:42:27  <Tekky> hehe, I'll be going to bed now, good night everyone!
03:42:34  <Frostregen> gn
03:45:09  *** Tekky [] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
03:45:31  *** flowOver [] has joined #openttd
03:52:01  *** Crabman [] has quit []
04:00:11  *** Gekz_ [] has quit [Quit: leaving]
04:38:14  *** Rexxars [~rexxars@] has quit [Quit: edgepro: A man who smiles when things go wrong knows who to blame.]
04:39:38  *** Vikthor [] has joined #openttd
04:52:40  *** Vikthor [] has quit [Quit: Leaving.]
04:54:48  *** Reemo [] has quit [Quit: - das Wiki rund um's Thema Lager und Logistik]
05:02:28  *** dlunch [~dlunch@] has quit [Remote host closed the connection]
05:02:56  *** dlunch [~dlunch@] has joined #openttd
05:12:48  <CIA-5> OpenTTD: rubidium * r14062 /trunk/src/ai/trolly/trolly.cpp: -Fix [FS#2226]: division by 0 in newai.
05:37:56  *** Suisse[Dodo]12ILvVgnnu [] has joined #openttd
05:41:18  *** Suisse [] has quit [Ping timeout: 480 seconds]
05:56:25  *** Sir-Bob [] has joined #openttd
05:56:55  *** Zorni [] has joined #openttd
06:01:25  <Frostregen> ;)
06:04:17  *** Zorn [] has quit [Ping timeout: 480 seconds]
06:05:15  <CIA-5> OpenTTD: rubidium * r14063 /trunk/src/ (19 files in 3 dirs): -Codechange: replace some "magic" constants with enumified constants.
06:07:10  *** Ridayah_ [] has joined #openttd
06:08:49  *** Ridayah [] has quit [Read error: Connection reset by peer]
06:13:27  <peter1138> Hehe, copying the map to do multithreaded drawing... how silly :D
06:13:57  <Rubidium> yeah, copying the map's not enough
06:14:02  <peter1138> Quite.
06:19:02  *** dlunch [~dlunch@] has quit [Remote host closed the connection]
06:20:35  *** mikl [] has joined #openttd
06:22:17  <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.
06:45:47  *** Suisse[Dodo]12ILvVgnnu is now known as Suisse
06:47:27  <peter1138> \o/
06:48:44  *** flow0ver [] has joined #openttd
06:51:19  *** ob0t_ [] has joined #openttd
06:51:50  *** Frostregen [] has quit [Quit: und weg]
06:52:19  *** ob0t [] has quit [Read error: Connection reset by peer]
06:52:19  *** Eddi|zuHause [] has quit [Remote host closed the connection]
06:52:40  *** Eddi|zuHause [] has joined #openttd
06:54:06  *** flowOver [] has quit [Ping timeout: 480 seconds]
07:04:04  *** mikl [] has quit [Quit: Leaving...]
07:07:12  *** Rexxars [~rexxars@] has joined #openttd
07:15:42  <peter1138> Rubidium, except that 31 bytes is not very much :(
07:15:47  <peter1138> Not enough at all.
07:18:39  <peter1138> We should change that to characters if possible.
07:22:24  <planetmaker> morning
07:24:45  *** flowOver [] has joined #openttd
07:24:53  *** SquireJames [SquireJame@] has quit []
07:27:34  <De_Ghost> soooooooo peter1138
07:27:42  <De_Ghost> when is signal in tunnel comming ? :D
07:28:00  <De_Ghost> you made that esk yet?
07:28:03  <De_Ghost> desk*
07:30:16  *** flow0ver [] has quit [Ping timeout: 480 seconds]
07:33:05  *** thingwath [] has joined #openttd
07:38:39  <peter1138> I'm not doing signals in tunnels.
07:39:13  <Fennec> haha.
07:39:27  <Fennec> don't blameya
07:41:49  *** Brianetta [] has joined #openttd
07:42:54  <Rubidium> peter1138: I haven't changed any limits whatsoever
07:43:17  <peter1138> I noticed.
07:43:25  <peter1138> My point still stands :)
07:45:16  *** TinoM [] has joined #openttd
07:47:35  *** TinoM [] has quit []
07:57:51  * Rubidium is amazed by the "security" world
07:59:06  <Rubidium> making a fuzz about something that's hardly remotely trigerrable and not mentioning the thing that's easily remotely triggerable
08:02:18  <ln> hmm, someone has stolen tons of rails in northern finland.
08:02:55  <ln> from a track abandoned long ago.
08:02:59  <Fennec> metal is $$$ these days.
08:03:00  <peter1138> De_Ghost, nearly complete ;)
08:03:36  <peter1138> What the hell happened to Classic FM's ident?
08:04:25  <ln> the interesting thing is that keeping the track and not demolishing it is part of the peace treaty between Soviet Union and Finland.
08:07:32  *** Brianetta [] has quit [Quit: TschÌß]
08:09:39  <De_Ghost> what wood did u use/.
08:12:10  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
08:12:50  <peter1138> ln, so Russia will start another war? Heh
08:14:40  <ln> that's what i'm expecting
08:15:48  <thingwath> is that treaty still effective, if there is no Soviet Union for more than 15 years? :)
08:16:10  <Noldo> thingwath: that is an interesting question
08:16:21  <ln> it shouldn't matter that the track has been unused since 40's, and has been partially demolished on the Russian side.
08:16:46  <Noldo> ln: do you know if it's the same treaty that limited number of fighter jets?
08:16:59  <thingwath> ln: so not Russia should invade Finland, but Finland should invade Russia :)
08:17:31  <ln> thingwath: that has been tried, with temporary success.
08:17:40  <Noldo> :)
08:17:55  <thingwath> I mean after 40's :)
08:17:57  <ln> Noldo: dunno, but i would assume there is only one treaty...
08:18:35  <Noldo> ln: anyway the fighter jet limit was broken when buing hornets
08:20:10  <ln> oops
08:20:18  <Noldo> ln: olso it seems we were forbidden from buying military material from germany
08:20:22  <Noldo> *also
08:23:43  <ln> which germany?
08:25:57  <Noldo> haha, now that is an interesting question
08:33:21  <Noldo> it doesn't say, just "Finland shall not buy or manufacture military material of german origin or model"
08:34:36  *** peter1138 [] has quit [Ping timeout: 480 seconds]
08:36:59  *** peter1138 [] has joined #openttd
08:37:00  *** mode/#openttd [+o peter1138] by ChanServ
08:37:36  *** mikl [] has joined #openttd
08:51:58  *** CelestarT42p [] has joined #openttd
08:52:00  <CelestarT42p> heyo
08:52:08  *** tokai|madspace [] has quit [Ping timeout: 480 seconds]
08:52:28  <Ailure> hmm
08:52:29  <Ailure> haha
08:52:32  *** fonso [] has joined #openttd
08:52:37  <Ailure> neat newGRF presets
08:52:53  <CelestarT42p> peter1138: got a minute?
08:54:35  *** tokai|madspace [] has joined #openttd
09:00:59  *** mucht_work [~Martin@] has joined #openttd
09:01:52  *** mucht_work [~Martin@] has quit [Remote host closed the connection]
09:06:53  *** mucht_work [~Martin@] has joined #openttd
09:17:41  *** Eddi|zuHause [] has quit [Remote host closed the connection]
09:18:01  *** Eddi|zuHause [] has joined #openttd
09:22:42  *** Wolf01 [] has joined #openttd
09:22:56  <Wolf01> hello
09:25:44  *** Farden [] has joined #openttd
09:37:48  *** Bjarni [] has joined #openttd
09:37:49  *** mode/#openttd [+o Bjarni] by ChanServ
09:38:05  *** Yorick [] has joined #openttd
09:39:40  <peter1138> CelestarT42p, sup?
09:43:50  <CelestarT42p> peter1138: sorry, galadriel apparently crashed
09:44:18  <CelestarT42p> peter1138: so I have some local changes, how can I propagate them, and do you have some place to pull changes from?
09:46:34  <CelestarT42p> well, galadriel didn't crash but the ssh daemon is down :S
09:46:46  <Yorick> Kloopy: are you there?
09:49:11  <CelestarT42p> peter1138: cuz I'm behind a NAT
09:51:10  *** divo [] has joined #openttd
09:51:15  <Kloopy> Hi Yorick, yeah.
09:51:17  <Kloopy> I have the file!
09:51:21  <Yorick> k :)
09:51:25  <Kloopy> Give me a mo.
09:51:32  <Yorick> :)
09:51:38  <Kloopy> Indeed
09:51:59  <peter1138> Oh, right...
09:52:06  *** divo [] has quit []
09:52:10  <peter1138> Well you can hg serve your local changes ;)
09:52:20  <peter1138> My copy isn't synced with yours thouhg.
09:52:21  *** divo [] has joined #openttd
09:52:23  <CelestarT42p> peter1138: behind the NAT?
09:52:43  <CelestarT42p> I got another server, but there's no copy, so I need to start with summin
09:52:53  <peter1138> Well, mine is behind NAT ;)
09:53:02  <peter1138> Hang on, I've got another copy.
09:53:08  <Kloopy> Yorick:
09:53:17  <CelestarT42p> peter1138: cool
09:53:26  <peter1138>
09:53:39  <peter1138> Not updated since Friday though.
09:54:30  <CelestarT42p> perfect (=
09:55:15  <Yorick> Kloopy: are you sure mass depot service, autoreplace, autorenew, or newgrfs are not used?
09:55:30  <peter1138> Is mass depot service unsafe too?
09:55:35  <Kloopy> I asked everyone if they were using autoreplace and they all promised they were not.
09:55:43  <Kloopy> It's only 3 years into the game so there is no autorenew happening.
09:55:49  <Kloopy> And 100% sure there are no grfs used.
09:56:09  <CelestarT42p> Kloopy: what are we talking about? (=
09:56:09  <Yorick> peter1138:
09:56:23  <Yorick> he's got reproducable desyncs on vanilla openttd
09:56:26  <Kloopy> CelestarT42p: a game that desynced based on a vanilla nightly over the weekend.
09:56:38  <CelestarT42p> er?
09:56:43  <CelestarT42p> not good
09:56:49  <Yorick> nono
09:56:51  <Yorick> debuggable
09:58:42  *** dvo [] has joined #openttd
09:58:42  *** divo [] has quit [Read error: Connection reset by peer]
10:00:54  <peter1138> ...
10:00:56  <dih> i only run vanilla nightlies - and saw quite a few desincs at some point too - just cannot remember when it was :-P
10:01:08  <peter1138> Yorick, but mass depot service does not mean autoreplace...
10:01:54  <Yorick> I don't know mass depot autoreplace
10:02:08  <peter1138> That's what the report said.
10:03:55  *** fmauNekAway is now known as fmauNeko
10:03:56  <CelestarT42p> erm peter1138 .. I have a new repo on
10:04:12  <CelestarT42p> peter1138: is that the latest of your stuff?
10:07:54  <Yorick> Kloopy: when does the desync happen?
10:08:12  <Kloopy> It was about a minute after unpausing. I can't say for 100% sure.
10:08:34  <peter1138> CelestarT42p, no, my home PC is down.
10:08:57  <dih> Rubidium: i noticed another thing with the console gui this time
10:09:09  <dih> there are no line breaks
10:09:45  <dih> i.e. a chat message that is a wee bit too long cannot be read in the console gui
10:09:51  <dih> at least not fully
10:10:06  <CelestarT42p> peter1138: k np then
10:10:24  <Yorick> Kloopy: I can't reproduce your desync
10:10:37  <peter1138> In my version non-destinations does not work, but I don't know if that was fixed.
10:10:50  <Kloopy> Ah man.. that sucks... I'll try here and see if I can.
10:12:59  <peter1138> Can anyone reach on port 25?
10:13:08  <CelestarT42p> checking
10:13:49  <CelestarT42p> peter1138: nmap sais filtered
10:13:58  <CelestarT42p> peter1138: can't telnet into it
10:14:14  <peter1138> Good.
10:14:14  <peter1138> Thanks.
10:15:05  *** Prof_Frink [] has joined #openttd
10:15:52  <CelestarT42p> peter1138: so our real desync test will have to wait till the probs in trunk are fixed (if there are some)
10:15:55  <CelestarT42p> or not?
10:16:39  <peter1138> Possibly. I don't know if frosch's autoreplace patch has had much testing yet.
10:16:40  <Rubidium> auto* needs to be fixed for sure
10:16:55  <CelestarT42p> Rubidium: what other elements are in "*" except replace?
10:17:01  <CelestarT42p> peter1138: he did a rewrite already?
10:17:07  <Rubidium> CelestarT42p: renew
10:17:13  <peter1138> autobjarni :D
10:17:33  <peter1138> All bjarni's stuff breaks ;)
10:17:36  <Yorick> Rubidum: frosch123 is assined to it :)
10:17:39  <peter1138> autoreplace, osx port...
10:17:45  <CelestarT42p> what's the problem with autorenew?
10:17:55  <peter1138> CelestarT42p, it's the code path as autoreplace.
10:17:55  <CelestarT42p> I mean apart from the fact that is sometimes fails for no reason :P
10:18:26  <CelestarT42p> peter1138: I see. Maybe we should conduct the test then without any autoreplace or summin
10:18:37  <Yorick> I think the new autoreplace should be vehicle-specific
10:18:42  *** Brianetta [] has joined #openttd
10:18:51  <Rubidium> CelestarT42p: that's hardly controllable
10:18:54  <peter1138> You're entitled to think what you like.
10:19:00  <peter1138> Morning Brianetta.
10:19:11  <Brianetta> Hello (:
10:19:18  <CelestarT42p> hey Brianetta
10:19:18  <dih> hello Brianetta
10:19:25  <Yorick> also the vehicle callback is tested without DC_EXEC too
10:19:27  <Brianetta> Just thought I'd pop on, between crises
10:19:30  <Yorick> hello Brianetta
10:19:36  <CelestarT42p> peter1138: hg pull should work for a merge?
10:19:43  <peter1138> Yes.
10:20:11  <CelestarT42p> er .. 404 :P
10:20:24  <CelestarT42p> hg
10:20:27  <CelestarT42p> openttd/trunk.hg
10:20:47  <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.
10:21:07  <CelestarT42p> 66 files updated, 35 files merged, 0 files removed, 3 files unresolved
10:21:12  <CelestarT42p> I *think* I fucked this up
10:21:16  *** Eddi|zuHause [] has quit [Remote host closed the connection]
10:21:21  <peter1138> Nope, just 3 files to manually merge.
10:21:31  *** Eddi|zuHause [] has joined #openttd
10:21:41  <CelestarT42p> that many changes? :o
10:21:50  <Eddi|zuHause> what's wrong today?
10:21:52  <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?
10:21:59  <peter1138> Language updates change a lot of files ;)
10:22:16  <Eddi|zuHause> it's the 3rd time i get disconnected from oftc today
10:22:22  <peter1138> Probably not, Brianetta.
10:22:49  <Brianetta> Well, since I have SVN all set up and working, I'll stick with it.
10:23:05  <Eddi|zuHause> hg is useful if you do local development, like a patch
10:23:14  <Brianetta> That's rare
10:23:22  <Brianetta> I'm more of an apply and test kind of guy
10:23:29  <peter1138> An hg clone contains everything, including history. So it's useful for development, but not really just testing a patch.
10:23:30  <Eddi|zuHause> then hg is not the right tool ;)
10:24:11  <CelestarT42p> heh
10:24:14  <CelestarT42p> hg view is neat :P
10:24:21  <Brianetta> I'm impressed that so many revision control systems work together
10:24:37  <Yorick> Brianetta: hg has a svn convert tool
10:24:39  <peter1138> It is next, yes.
10:24:46  <Eddi|zuHause> hg view is fun when you have multiple parallel development lines ;)
10:24:57  <peter1138> Eddi|zuHause, which we do :)
10:25:10  <CelestarT42p> Eddi|zuHause: yeah
10:25:17  <Brianetta> So hg would be ideal if you were maintaining an integrated nightly
10:25:28  <CelestarT42p> peter1138: although the "some kind of merge" did mess it up :P
10:25:30  *** Dred_furst [] has joined #openttd
10:25:34  <Eddi|zuHause> yes, for example
10:25:54  <peter1138> Yes, that did.
10:26:12  <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. :(
10:26:19  *** stillunknown [] has joined #openttd
10:26:20  <peter1138> But that was because the original hg repo was replaced with a complete one, so not actually my fault.
10:26:22  <Brianetta> Kloopy: Did you have trams?
10:26:27  <Kloopy> No, no GRFs.
10:26:32  <Yorick> Brianetta: no grfs were used
10:26:37  <Brianetta> Cool.
10:26:55  <Brianetta> This weekend, I plan to run a local server at my home, and do some intensive testing.
10:27:00  <Brianetta> See if I can't get it to desync.
10:27:01  <CelestarT42p> peter1138: yeah :P
10:27:09  <Brianetta> My Standard Server is desyncing all players at the moment
10:27:26  <Brianetta> and still is, even though I saved, exited and reloaded the dedicated server
10:27:35  <Brianetta> so it wasn't a one-off cause
10:27:39  <Yorick> but it's using grfs
10:27:44  <Dred_furst> Mine is too,
10:27:47  <Brianetta> It is.  It still shouldn't desync.
10:27:51  <Yorick> and afaik desync-debug isn't in 0.6.2
10:27:54  <Rubidium> without it being reproducable for us... we can't do a thing about it
10:28:10  <Kloopy> Of course Rubidium.
10:28:11  <Brianetta> Rubidium: I'm aware.  That's why I'm going to try some testing this weekend.
10:28:12  <Dred_furst> people are reporting monthly desyncs on mine
10:28:18  <Dred_furst> and the autosave is monthly
10:28:23  <CelestarT42p> autoreplace?
10:28:28  <Yorick> autosave
10:28:31  <Dred_furst> Autosave.
10:28:41  <Yorick> auto*
10:28:41  <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.
10:28:44  <Rubidium> 0.6.x shouldn't be influenced by the autoreplace crapness of trunk
10:29:41  <Brianetta> 0.6.2 is not desyncing because of any player action, gui, command or otherwise.
10:29:49  <Yorick> I think autoreplace should be removed from trunk completely, or disabled...
10:30:01  <Brianetta> It's desyncing when I connect as the only player, and just watch the trains.
10:30:16  <Brianetta> Yorick: It's fine in 0.6.2; removal isn't necessary
10:30:35  <Yorick> Brianetta: _trunk_ ;)
10:30:49  <Rubidium> Yorick: and what would be the reason to do so?
10:31:00  <Yorick> the crapness?
10:31:07  <Rubidium> then don't use trunk
10:31:10  <peter1138> I haven't seen Yorick's patch to fix it.
10:31:12  <Rubidium> people are working on fixing it
10:31:39  <CelestarT42p> so 0.6.2 is desyncing as well?
10:32:05  <Rubidium> well, there never was a version that didn't desync
10:32:14  <CelestarT42p> Dred_furst: why don't you set autosave on quarterly and see what happens=?
10:32:44  <Dred_furst> I always notice my games stall a bit when it autosaves
10:32:45  <Yorick> could be news messages too
10:32:54  <Dred_furst> (in SP)
10:33:01  <CelestarT42p> Dred_furst: well, sure
10:33:07  <Rubidium> news messages don't change the game state
10:33:13  <CelestarT42p> Dred_furst: unless you have > 1 CPUs
10:33:29  <Dred_furst> if the server stalls a bit and the client's aren't auto saving the server will desync
10:33:36  <Yorick> wasn't there a bug with 0.6.1-RC1 and desyncs and news messages?
10:33:44  <Dred_furst> how does the no. of CPU's change how it reads the map?
10:33:45  <peter1138> Dred_furst: Wrong.
10:33:47  <Yorick> Dred_furst: wrong
10:33:51  <Rubidium> Yorick: no
10:33:59  <Yorick> something with PACKET_SERVER_FRAME?
10:34:01  <peter1138> The server can never desync. It is authoritative.
10:34:06  <Dred_furst> that was my stab in the dark anyway
10:34:18  <Dred_furst> ok it would cause the clients to desync
10:34:31  <Yorick> Dred_furst: still wrong
10:34:32  <peter1138> It wouldn't, anyway.
10:34:34  <Dred_furst> unless the clients stall a bit too
10:34:47  <Yorick> Dred_furst: the clients wait for the server
10:34:52  <peter1138> If the server stalls too long, then the clients might disconnect, but that is not a desync.
10:34:53  <Dred_furst> you guys know the code base much better than I do
10:35:09  <Dred_furst> so what would be the reason for a desync?
10:35:17  <CelestarT42p> Dred_furst: different PRNG results
10:35:22  <CelestarT42p> Dred_furst: that's the ONLY reason
10:35:23  <Yorick> Dred_furst: you tell us :)
10:35:43  <Dred_furst> What on earth are different PRNG results
10:35:46  <Yorick> CelestarT42p: no, different amount of calls to PRNG
10:35:52  <CelestarT42p> Yorick: same difference
10:35:55  <peter1138> Pseudo random number generator.
10:36:01  <CelestarT42p> Dred_furst: what peter1138 said
10:36:16  <Yorick> Dred_furst: what CelestarT42p said
10:36:32  <Dred_furst> Ok, so I guess the PRNG is used in identifiying network packets?
10:36:32  <CelestarT42p> Yorick: but even with the same amount of calls the results may be different
10:36:41  <CelestarT42p> Dred_furst: no, it used in the game engine
10:36:50  <Dred_furst> how/why
10:36:51  <Yorick> CelestarT42p: would they?
10:37:00  <peter1138> CelestarT42p, then that's a faulty PRNG.
10:37:14  <Dred_furst> Why don't you get the server to tell the clients what random number to use?
10:37:17  <CelestarT42p> Yorick: peter1138 buffer overflow into the seed can be a reason (I think we had that once, didn't we?)
10:37:21  <CelestarT42p> Dred_furst: bandwidth
10:37:28  <Dred_furst> how often is it called?
10:37:39  <CelestarT42p> Dred_furst: enable desync debug and you'll see
10:37:41  <CelestarT42p> OFTEN
10:37:46  <Rubidium> enough to make a 100 MB log a minute
10:37:52  <Dred_furst> Right ok
10:37:56  <Yorick> CelestarT42p: then it would be far more common
10:38:11  <Dred_furst> then the second question is why would the client call the PRNG more times than the server?
10:38:21  <Dred_furst> or vice versa
10:38:21  <Yorick> Dred_furst: that is the bug
10:38:24  <peter1138> Due to different state.
10:38:42  <CelestarT42p> or different codebases (theoretically)
10:38:49  <Dred_furst> then you need a system to roll back a state and catch up with the server
10:38:55  <Yorick> if (!_network_server) Random();
10:39:05  <peter1138> The most usual cause these days is cached data not matching between server and clients.
10:39:09  <Rubidium> Dred_furst: and how far do you need to roll back?
10:39:22  <Dred_furst> I guess you would have to provide hashes
10:39:30  <CelestarT42p> Dred_furst: we have that. Just re-connect :P
10:39:34  <Yorick> ^^
10:39:45  <Dred_furst> Make the game sort itself out, rather than reconnect
10:39:51  <peter1138> Gah, why do PC cases suck so bad?
10:39:58  <CelestarT42p> Dred_furst: auto-reconnect on desync?
10:40:06  <Dred_furst> per say
10:40:06  <Yorick> Dred_furst: sorting itself out = reconnect
10:40:11  <peter1138> The solution is to fix all desyncs, not work around them.
10:40:14  <CelestarT42p> peter1138: dunno. Made in Taiwan probably :P
10:40:19  <peter1138> Ah, probably.
10:40:37  <CelestarT42p> peter1138: or change the architecture and have a server/client system instead of a P2P system
10:40:37  <peter1138> The base simple case I've seen recently is microATX :(
10:40:54  <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
10:40:54  <peter1138> P2P?
10:40:59  <CelestarT42p> peer-to-peer
10:40:59  <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.
10:41:06  <peter1138> What is peer-to-peer?
10:41:32  <Yorick> client to client
10:41:40  <CelestarT42p> peter1138: basically the openttd networking is peer-to-peer (logically, not networkically)
10:41:46  <Rubidium> Brianetta: what's much quicker and more efficient is dumping the random calls to a file and diff that
10:41:48  <peter1138> No it's not.
10:41:50  <Dred_furst> I guess if you encounter a desync, force the PRNG to reset with a new seed
10:41:50  <CelestarT42p> every client has a full state
10:42:00  <Brianetta> Rubidium: Admittedly, true
10:42:02  <Dred_furst> and the server can broadcast this to the clients
10:42:07  <CelestarT42p> Dred_furst: and what seed would that be?
10:42:15  <Yorick> Dred_furst: the map is still likely to be different then
10:42:25  <Rubidium> Brianetta: and you can force to check sync every frame
10:42:28  *** Roujin [] has joined #openttd
10:42:35  <Dred_furst> one randomly generated by the OS
10:42:51  <Yorick> Dred_furst: for all clients?
10:43:04  <CelestarT42p> Dred_furst: and how do you make sure that we have identical maps on all the clients?
10:43:05  <Dred_furst> generate the seed on the server, distrobute to the clients
10:43:23  <peter1138> How would that help? The game state is already wrong.
10:43:24  <Dred_furst> ok, How many bytes per map tile is there?
10:43:25  <CelestarT42p> Dred_furst: when the game desyncs, the state HAS diverged already
10:43:28  <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
10:43:35  <CelestarT42p> Dred_furst: one and a little bit :P
10:43:37  <Yorick> Dred_furst: landscape_map.h
10:43:42  <Yorick> Dred_furst: landscape_map.html
10:43:43  <Dred_furst> ok let me grab the code
10:43:52  <CelestarT42p> Dred_furst: you don't have to upload the map only
10:43:56  <Rubidium> Dred_furst: 10-ish per tile
10:43:57  <CelestarT42p> Dred_furst: but the entire savegame
10:44:08  <CelestarT42p> er .. 10 and a little bit :P
10:44:21  <Rubidium> CelestarT42p: where does the little bit come from?
10:44:23  <Brianetta> Rubidium: If you want me to do this this weekend, send me details.  I'll use a clone of my server setup.
10:44:33  <Dred_furst> You could generate a diff between the two, but then one of the machines needs a copy of the other's game
10:44:34  <CelestarT42p> Rubidium: sorry, mixed up bits and bytes just now (=
10:44:50  <CelestarT42p> Dred_furst: yes. that's called connecting. Client loads current gamestate from server :P
10:44:51  <Yorick> Dred_furst: around 72 bits
10:45:07  <peter1138> There is more to the game state than the map, heh...
10:45:13  <Eddi|zuHause> we should really transfer the savegame 30 times per second ;)
10:45:19  <Dred_furst> no
10:45:23  <Dred_furst> I am never going that far
10:45:25  <peter1138> Bah, I want front panel audio and USB but not firewire...
10:45:27  <CelestarT42p> Eddi|zuHause: how about a diff of the savegame (=
10:45:37  <Eddi|zuHause> oh, much better :)
10:45:39  <Dred_furst> CelestarT42p, one problem
10:45:48  <Dred_furst> you cannot create the diff easily
10:45:53  <CelestarT42p> memcpy :P
10:45:58  <CelestarT42p> and write memdiff :P
10:45:58  <Dred_furst> mainly as the two machines have different states
10:46:06  <peter1138> Hehe, there was one guy on here who thought we used the server's ability to draw to draw the client views...
10:46:08  <Rubidium> Brianetta: ./configure --enable-desync-debug=2 for the server and client, then make, ./openttd > logfile and then diff both logfiles after the desync
10:46:25  <Yorick> peter1138: rdp :)
10:46:27  <Rubidium> after that you go backtracking the issue, usually by adding more output using printfs
10:46:59  <CelestarT42p> Eddi|zuHause: We could also only send the things which actually change the gamestate in an unpredictable way like the commands (=
10:47:06  <CelestarT42p> Eddi|zuHause: er wait, that's what we do :P
10:47:12  <Yorick> Brianetta: you need a reproducable desync first
10:47:38  *** Progman [] has joined #openttd
10:48:02  * peter1138 still wonders about saving all cached results from NewGRF instead of recalculating them.
10:48:10  <peter1138> (That, or forcing recalculation for all)
10:48:50  <CelestarT42p> Step 5
10:48:50  <CelestarT42p> Desync found, and likely a whole day further.
10:48:52  <CelestarT42p> ROFL
10:48:54  <CelestarT42p> a day?
10:48:57  * Yorick knows nothing about desync
10:48:58  <CelestarT42p> you guys been lucky :P
10:49:14  <CelestarT42p> Yorick: well if you read, you know what a desync is now :P
10:49:24  <Yorick> I did already
10:49:28  <Yorick> newgrf*
10:49:30  <CelestarT42p> heh
10:50:19  <CelestarT42p> Rubidium: we add output using cout :P
10:50:46  *** Eddi|zuHause [] has quit [Remote host closed the connection]
10:51:08  *** Eddi|zuHause [] has joined #openttd
10:51:37  <CelestarT42p> or cerr rather :P
10:53:54  <CelestarT42p> peter1138:
10:54:46  <peter1138> That was the old one.
10:54:51  <CelestarT42p> peter1138: shall we remove all this from the wiki?
10:54:56  <Rubidium> old-old-old-old-old one
10:54:57  <peter1138> Yup.
10:55:10  <CelestarT42p> heh .. how :P
10:55:13  <peter1138> I can do it.
10:55:20  <Dred_furst> how much bandwidth does the game require currently to run effectively with 10 people
10:55:22  <CelestarT42p> I don't have a my login here
10:55:25  <peter1138> Gone.
10:55:45  <CelestarT42p> Dred_furst: about 2Kb/(client sec)
10:56:06  <CelestarT42p> Dred_furst: and it's basically flat-rate
10:56:06  <Dred_furst> and I am right in thinking the game uses a decentralized system with the server being authoritive?
10:56:20  <CelestarT42p> Dred_furst: yes. Each client has the full game state
10:56:40  <Dred_furst> so are some of the client's sending events to each other?
10:56:52  <Yorick> nope
10:56:53  <CelestarT42p> er nope
10:57:00  <Dred_furst> so it isn't decentralized at all
10:57:02  <Yorick> they send commands to the server
10:57:04  <Dred_furst> its client/server
10:57:11  <CelestarT42p> otherwise you'll open a can-of-worms with NAT
10:57:13  <Yorick> which relays them to every other client
10:57:20  <CelestarT42p> Dred_furst: the only thing the client sends are Commands
10:57:24  <Dred_furst> Yes
10:57:33  <Dred_furst> Ok right just wanted to make sure that was correct
10:57:46  <CelestarT42p> server checks them, if it authorizes them, puts them onto all othe clients
10:57:52  <CelestarT42p> (at the same frame)
10:58:22  *** Tekky [] has joined #openttd
10:58:26  <Dred_furst> and another guess of why things desync is packet loss?
10:58:26  <CelestarT42p> heyo Tekky
10:58:37  <Tekky> hi everyone :)
10:58:40  <Dred_furst> or is it designed to cope with packet loss
10:58:47  <CelestarT42p> Dred_furst: this is TCP (=
10:58:48  <Rubidium> Dred_furst: TCP has NO packetloss
10:58:53  <CelestarT42p> NOT udp
10:59:00  <CelestarT42p> that's why we're using it
10:59:02  *** lobster_MB [~michielbr@] has joined #openttd
10:59:10  <Rubidium> it only has connection loss, which is a completely different error
10:59:35  <CelestarT42p> Rubidium: is there a maximum retransmission value?
11:00:02  <Rubidium> I reckon there is in TCP
11:00:04  <CelestarT42p> or does TCP just keep trying until it drops the connection
11:00:20  * CelestarT42p guess if you hit the maximum retransmission value, you might have another problem :P
11:00:34  <Rubidium> if you hit that maximum the connection will be dropped
11:00:56  <Dred_furst> so if TCP needs a packet re-transmitted and it keeps trying and the next frame hits, desync
11:01:06  <Rubidium> no
11:01:26  <CelestarT42p> no
11:01:26  <Rubidium> TCP passes the data to the client in the same way it was send by the server
11:01:33  <Yorick> it also guarantees packet order
11:01:36  <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
11:01:42  <CelestarT42p> no
11:01:44  <Rubidium> whatever happens in between (retransmissions and such) aren't of any concern to the client
11:02:03  <CelestarT42p> the client is only a bit after the server then
11:02:07  <Rubidium> Dred_furst: no, you are "lagging", not out of sync
11:02:12  <Kloopy> TCP guarantees that packets arrive in the order they are sent, Dred_furst.
11:02:16  <Dred_furst> what I am saying is does the client hop forward to catch up with the server
11:02:19  <Rubidium> out of sync means: both games at the same tick and the game state differs
11:02:25  <Dred_furst> ok
11:02:33  <Rubidium> lagging means: server is a tick (or more) in front of the client
11:02:38  <CelestarT42p> Dred_furst: it can't skip frames
11:03:05  <Yorick> Dred_furst: it just fast-forwards or keeps at it's lagging speed and eventually disconnects
11:03:14  <CelestarT42p> Rubidium: isn't the server always a bit ahead of the clients?
11:03:27  <Dred_furst> so really you need to go through the network system and make sure it is all correct
11:03:33  <Dred_furst> and looking where the function calls are
11:03:47  <Yorick> Dred_furst: fortunatly we've got desync_debug
11:04:11  <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
11:04:22  <CelestarT42p> Rubidium: yeah
11:04:33  <peter1138> We don't need to, because the network system works fine.
11:04:38  <Dred_furst> then isn't that a problem
11:04:51  <Dred_furst> it obviously doesn't work fine, people still desync
11:05:02  <peter1138> A desync is not a network problem.
11:05:17  <Eddi|zuHause> desync is a LOGIC error, not a NETWORK error
11:05:39  <CelestarT42p> sematic error :P
11:05:42  <Noldo> :)
11:06:09  <CelestarT42p> semantic*
11:06:22  <Yorick> a desync is a bug, something done wrong by someone
11:06:46  <peter1138> Like using the PRNG within a command test :D
11:06:51  <Brianetta> [11:47] <Yorick> Brianetta: you need a reproducable desync first...
11:06:53  <peter1138> At least they're obvious.
11:06:54  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
11:07:07  <Brianetta> Yorick: I have a reproducable desync.  Just not a predictable one.
11:07:10  <CelestarT42p> peter1138: or an assignment in an assert
11:07:19  <peter1138> Have we had that?
11:07:24  <peter1138> I've seen user patches doing that...
11:07:24  <CelestarT42p> er ... only locally (=
11:07:27  <peter1138> Hehe
11:07:50  <Dred_furst> then go through the source and see where every call of the PRNG is
11:08:00  <Dred_furst> and strip it down to required calls
11:08:01  <Yorick> Dref_furst: good luck
11:08:11  <CelestarT42p> Dred_furst: and you think that's not already done (=
11:08:31  <Dred_furst> well SOMETHING is broken
11:08:39  <Rubidium> Dred_furst: duh!
11:08:55  <peter1138> Not all desyncs are caused by the PRNG, but the PRNG is used to detect them.
11:08:57  <Dred_furst> and the likely culprit is your PRNG
11:09:01  *** Doorslammer [] has joined #openttd
11:09:21  <Yorick> 192 source lines containing Random()
11:09:36  <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
11:09:55  <CelestarT42p> peter1138: someone might use the iPRNG where the nPRNG is used (or is that still used?)
11:10:00  <Rubidium> the last few years where things like slight differences in implementations of external libraries
11:10:05  <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.
11:10:14  <peter1138> CelestarT42p, yup. They're easy to spot though :)
11:10:15  <Rubidium> or NewGRFs fracking up
11:10:23  <CelestarT42p> peter1138: point taken
11:10:39  <CelestarT42p> the problem with NewGRFs is that they dig deeply into the engine
11:10:41  <CelestarT42p> VERY deeply
11:10:43  <Rubidium> Dred_furst: but please review all 150 thousand lines of actual code and find the desync that way
11:10:47  *** lobster_MB [~michielbr@] has joined #openttd
11:10:53  <Eddi|zuHause> or caches where the order of insertion is relevant
11:10:55  <Brianetta> Rubidium: Shouldn't a newgrf frack up in exactly the same way on client and server?
11:11:02  <Brianetta> The game is deterministic, isn't it?
11:11:10  <peter1138> Cache-coherency problems are spotted by the server and original clients staying on, but subsequent clients desyncing.
11:11:16  <peter1138> Hence "reload the server" fixes them.
11:11:25  <Eddi|zuHause> yes.
11:11:37  <Brianetta> My server first started desyncing people who weren't me
11:11:54  <Brianetta> When I eventually disconnected, I also got desynced
11:11:56  <peter1138> Until you disconnect and rejoin, and then you will desync too :)
11:11:56  <Rubidium> Brianetta, easy way to cause a desync: make NewGRF behave differently before 1970 than after it and start the server before 1970
11:11:58  <Yorick> your server stopped trusting strangers
11:12:00  <Brianetta> unfortunately, reloading the server didn't fix it
11:12:21  <Yorick> Rubidium: ttrs :)
11:12:23  <Brianetta> Rubidium: Wow...
11:12:56  <Yorick> openttd didnt exist back in 1970
11:12:59  <Yorick> and neither did I
11:13:03  <CelestarT42p> Brianetta: computers are deterministic, unless you have SBE due to SCR or GCR
11:13:03  <Eddi|zuHause> Yorick: it's fine as long as it is only graphically (e.g. road replacements)
11:13:17  <CelestarT42p> or similar events
11:13:29  <Eddi|zuHause> cosmic dust!
11:13:41  <Yorick> Eddi: ttrs got era's
11:13:48  <CelestarT42p> Eddi|zuHause: "SCR" and "GCR" is that :P
11:14:04  <Eddi|zuHause> i figured ;)
11:14:43  <Eddi|zuHause> Yorick: yes, but they are deterministic...
11:15:09  <Eddi|zuHause> houses store the year they were built in
11:15:14  <Eddi|zuHause> roads don't
11:15:19  <CelestarT42p> Rubidium: heh? how will that TTRS example cause a desync?
11:15:29  <Yorick> we need NoGRFs, grfs scripted in squirrel :P
11:15:30  <Brianetta> What happens in 1970?
11:15:48  <Brianetta> Specifically, what happens in 1970 that doesn't happen on both sides of a net connection?
11:15:56  <planetmaker> new roads IIRC
11:15:58  <CelestarT42p> good Q
11:16:03  <peter1138> Just graphical.
11:16:16  <planetmaker> and other buildings
11:16:52  <peter1138> Just the roads. Everything else is controlled by NewGRF.
11:17:19  <peter1138> Unless it changes bridge speeds too, but I don't think it does, heh...
11:17:33  <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
11:17:47  <planetmaker> I don't think it's modifying bridge speeds as function of time
11:18:04  <peter1138> The bridge styles change, certainly.
11:18:32  <planetmaker> hm... :) I won't contradict the newgrf guru :P
11:18:51  <Brianetta> "as a function of time" would be fine
11:19:10  <Yorick> oh spiritual descendant of the newgrf gods, load us with your wisdom
11:19:14  <Brianetta> If it's determining behaviour by the date *at which the grf is initialised* there's trouble
11:19:18  <Rubidium> too bad it's "as a function of time at game load"
11:19:41  <Eddi|zuHause> Brianetta: as long as there are no varaction2s, the "function of time" can only be calculated on load
11:20:14  <Brianetta> Perhaps the newgrf state should be in the save game, then, and the newgrfs themselves not initialised except at game creation time.
11:20:35  <CelestarT42p> Eddi|zuHause: that means the TTRS is not usable in the network?
11:21:02  <peter1138> Rubidium, we could fudge it to be 'at time of game start' ;)
11:21:06  <Eddi|zuHause> CelestarT42p: i don't know... like it's said, if it really only replaces graphics, it should be fine
11:21:14  <peter1138> But I don't think TTRS changes anything apart from cosmetics.
11:22:06  <Ammler> peter1138: newcargo?
11:22:20  <Brianetta> I'm wondering if the grvts.grf set does this
11:22:45  <peter1138> I mean based on date of game load.
11:23:07  <CelestarT42p> peter1138: so what's the plan for furthering cargodest?
11:23:47  <CelestarT42p> maybe I should write something about it on the wiki or so
11:23:49  <peter1138> We could make any GRF that uses action 7/9/D/etc using a date variable be marked as unsafe...
11:23:56  <peter1138> CelestarT42p, fixing it ;)
11:24:02  <peter1138> Assuming it's not already.
11:24:06  <CelestarT42p> peter1138: what's broken? :P
11:24:21  <peter1138> On my old game, no cargo would load at all until I changed everything to use destinations.
11:25:47  *** lobster_MB [~michielbr@] has quit [Ping timeout: 480 seconds]
11:25:59  <CelestarT42p> peter1138: cannot reproduce?
11:26:39  *** ecke [~ecke@] has joined #openttd
11:27:19  *** Sacro [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has joined #openttd
11:28:13  <CelestarT42p> peter1138: how about showing the destinations in the "total cargo" display. We gonna do that?
11:28:43  <CelestarT42p> g2g anyway
11:28:44  <CelestarT42p> cu later
11:28:45  *** CelestarT42p [] has quit [Quit: leaving]
11:28:48  <peter1138> W...
11:28:48  <peter1138> Oh
11:31:07  <Progman> thats my request \o/
11:31:36  *** Sir-Bob [] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
11:32:25  <Eddi|zuHause> peter1138: in the train details view
11:32:54  <peter1138> I was going to say I didn't have all his changes, heh...
11:33:03  <peter1138> Which might be why it didn't work properly.
11:33:36  <Yorick> shouln't strgen be included in bundles?
11:34:37  <Eddi|zuHause> Yorick: no, why?
11:34:59  <Yorick> it's missing with nightlies
11:35:22  <Yorick> people that want to make their own language files can't
11:35:23  <Eddi|zuHause> why would it be included? it's not necessary to run the game
11:35:38  <Eddi|zuHause> plus, strgen hardly ever changes
11:35:53  <Rubidium> Yorick: english.txt isn't in the nightlies either
11:36:07  <Rubidium> ergo: they can't anyway when you include strgen
11:36:16  <Yorick> Eddi: well it did
11:37:33  <Rubidium> nobody seems to have missed it
11:38:05  <Eddi|zuHause> Yorick: on average, it changes once every 1000 revisions
11:40:15  <Yorick> Rubidium: I have
11:40:49  <Rubidium> after 1.5 years
11:41:01  <Eddi|zuHause> Yorick: the amount of people who need strgen and don't compile themselves is negligible, it would not be worth the effort
11:41:53  *** Bjarni [] has quit [Quit: Leaving]
11:42:21  <Rubidium> furthermore the strgen made by the compile farm's useless for most people as it's a linux version of it
11:43:59  <peter1138> Translators should use WT2.
11:44:06  <peter1138> Is that opened yet?
11:44:33  *** lobster_MB [~michielbr@] has joined #openttd
11:45:15  <Yorick> peter1138: so everyone except the translators is excluded from getting a translation into openttd
11:46:01  <peter1138> No. If you getting a translation into OpenTTD then the idea is you become a translator...
11:46:08  <peter1138> +are
11:46:53  <peter1138> WT2 (I believe) tracks things like changes to the English files, which a manual translation might miss.
11:52:34  <Brianetta> Nearly 4/11ths of the way to the OpenTTD server target (:
11:53:09  <Brianetta> Anybody know how many donations have been made?  Implication is, what's the average donation?
11:53:23  <hylje> over nine thousand
11:53:24  <Yorick> I wonder if it is needed to compile any *_gui.cpp file for dedicated servers
11:53:26  <Sacro> OpenTTD server target?
11:53:48  <Brianetta> Sacro:
11:54:27  <Ailure> hmm
11:54:28  <Rubidium> Yorick: ideologically not, but there're references to the GUI in the normal code that need to be "resolved" first
11:54:30  <Sacro> oh so *thats* why all the donations orudge was on about where coming in
11:54:33  <Ailure> Neat
11:54:40  <Yorick> Rubidium: empty functions?
11:54:41  <Ailure> That's alot of donations in a such short timeframe
11:55:07  <Rubidium> Yorick: that's a quick and lazy fix
11:55:08  <orudge> Sacro: quite
11:55:10  <Brianetta> I might have been the first to donate
11:55:20  <orudge> You were.
11:55:22  <Sacro> I has no spare monies at the moment :(
11:55:22  <Brianetta> Which would explain the hug I got off TrueBrain
11:55:25  <Rubidium> Yorick: as there are quite some functions that are in _gui.cpp that don't belong there and vice versa
11:55:45  <Sacro> Brianetta: that or truebrain saw your picture and took a liking
11:55:47  <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
11:55:51  <Yorick> Brianetta: TrueBrain is strange with hugging and kicking
11:55:54  <orudge> (most donations tend to be in the order of €10 - €15)
11:56:04  <Brianetta> Cool.  So, the average seems to be €10
11:56:42  <Brianetta> A hundred more like that meets the target.
11:57:00  <Sacro> why can people not csount
11:57:02  <dih> Yorick: no TrueBrain is quite reliable with that :-P
11:57:29  <Brianetta> Our goal is to raise £486 (or €0620)
11:57:33  <Yorick> dih: he doesn't kick you...
11:57:38  <Brianetta> orudge: That's €400 to a Unix beard
11:57:41  <Eddi|zuHause> Sacro: same as why people can not wsrite ;)
11:57:48  <Brianetta> since the leading 0 implies an octal number
11:58:00  <orudge> heh
11:58:12  <Sacro> Eddi|zuHause: hush you
11:58:28  <Ailure> I would easily donate about 500 SEK if I wasn't so poor at the moment.
11:58:35  *** glx [] has joined #openttd
11:58:35  *** mode/#openttd [+v glx] by ChanServ
11:58:35  <Ailure> That's about 40 pounds
11:58:38  <dih> Yorick: i have had my fair share of kicks ;-)
11:58:45  <Ailure> ...and that's just slightly more expensive how a new game costs here.
11:58:52  <orudge> Ailure: well, you can donate at any time, not just when there's a fundraiser on :)
11:58:53  <Sacro> i have 192 grivna going spare
11:58:59  <dih> besids, Yorick, is people start kicking you, you should start using your thinker
11:59:02  <dih> ;-)
11:59:04  <Ailure> Orudge: True :P
11:59:19  <Brianetta> This fundraiser has a specific goal, though
11:59:20  <Yorick> dih: he kicked himself yesterday
11:59:29  <dih> yes - also a fun thing to do :-P
11:59:43  <Yorick> whereafter he hugged himself
12:00:43  <Brianetta> woah
12:00:49  <Brianetta> Somebody just poured cash in
12:01:09  <Rubidium> nah, orudge woke up
12:01:22  <Brianetta> oh
12:01:34  <Brianetta> You can buy a crap server for colo already (:
12:01:36  <Yorick> wait - orudge has no cash
12:01:50  <Brianetta> Yorick: He has OpenTTD's cash for now
12:02:03  <Yorick> yes, but none of his own
12:02:14  <orudge> I have enough to get by on.
12:02:25  <orudge> plus a few hundred quid in trust for OpenTTD
12:02:39  <Brianetta> orudge: Enough to leave the country (:
12:02:53  <orudge> I've already booked my flight ;)
12:02:54  *** Forked [] has joined #openttd
12:03:06  * dih loves one way flights
12:03:14  <Sacro> quick, someone delete his destination airport
12:03:23  <orudge> then I'll circle the north pole for ever!
12:03:24  <orudge> well
12:03:26  <orudge> if you delete the source airport too
12:03:47  <dih> lol
12:03:47  * Sacro puts orudge's new destination as an oil rig
12:03:49  <Brianetta> orudge: This is an *OpenTTD* fundraiser.
12:03:51  <Sacro> now you're stuck
12:03:54  <Brianetta> You'll run out of fuel then explode.
12:03:59  <orudge> :(
12:04:08  <orudge> maybe we should have a TTDPatch fundraiser instead
12:04:12  <orudge> I'm less likely to die that way
12:04:18  * dih sends an oil tanker to the oil rig
12:04:23  <Brianetta> No; just trapped on a plane eternally
12:04:34  <orudge> which i guess would eventually have the same effect
12:04:42  * Brianetta raises an island near the oil rig and builds a long railway station
12:05:06  * dih sends some zeplins
12:05:19  * Yorick unloads av8
12:05:22  <dih> if i get orudge first i get way more money :-P
12:05:34  <dih> Yorick: BAD... never touch grf's in a running game
12:05:34  <Sacro> irc based openttd?
12:05:48  <Sacro> PBIMTTD!
12:05:50  <Forked> ===========  ..railwaytrack
12:05:55  * dih scrolls to tile 230
12:06:02  <Yorick> dih: your zeppelins just turned into flying pieces of railwaytrack
12:06:30  <dih> as long as they can transport people and i get (good) money for it, i am happy
12:06:41  <Yorick> no, they transport vehicles now
12:06:54  <dih> crap
12:07:07  <Yorick> and can't land without runways
12:07:08  <Brianetta> orudge uses a stretched blue dot for his fund raiser bar
12:07:12  <Brianetta> I'd have used css
12:07:17  <orudge> well, TrueBrain set that bit up
12:07:20  <orudge> I just edit it :)
12:07:31  <Ailure> heehehe
12:07:35  <Ailure> graphical bugs are fun
12:08:07  <Ailure> Like the shops and offices one
12:08:08  <dih> hello Ailure
12:08:24  <hylje> zomg its an Ailure
12:08:28  <Yorick> noes
12:08:39  <Ailure> which you only see if you put outlandish values in the configuration file for subsidaries
12:08:43  <orudge> ooh
12:08:45  <orudge> and another donation
12:08:49  <Ailure> So instead of a subsidary announcment, the string "shops and offices" comes up
12:09:10  <Ailure> and hello dih
12:09:15  <Yorick> orudge: how much?
12:09:32  <dih> Yorick: a donation ;-)
12:09:44  <dih> every donation is woth the same, even if they differ in value
12:09:57  <Ailure> In other words
12:10:06  <Ailure> I should divide my donations in many parts as possible
12:10:07  <Brianetta> dih: That's rubbish.  If you buy them a new server, it's so totally worth more.
12:10:09  <Yorick> dih: "those are the trades that annoy me" :)
12:10:10  <Ailure> to get the most worth out of it
12:10:16  <Ailure> :P
12:10:24  <dih> Yorick: nice quote :-D
12:10:49  <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 :)
12:11:01  <Brianetta> The donation appears to have been for £14.92
12:11:08  <orudge> that would be incorrect
12:11:09  <Brianetta> so probably not a Sterling donation
12:11:17  <orudge> the donation was about double that
12:11:21  <orudge> oh, wait
12:11:25  <orudge> I added up the wrong column
12:11:31  <orudge> let's try that again
12:11:33  <Sacro> 'tard
12:11:33  <Brianetta> haha
12:11:45  <dih> lol
12:12:04  <orudge> that's better
12:12:15  <Brianetta> £28.72
12:12:25  <Yorick> 30?
12:12:26  <orudge> well, £28.78
12:12:29  <orudge> it was a £30 donation
12:12:38  <Ailure> hmm
12:13:02  <Brianetta> So, are PayPal stealing cash?
12:13:05  <dih> you lose quite a bit of each donation...
12:13:18  <Brianetta> If I'd known, I'd have wired you the money
12:13:24  <dih> aye
12:14:28  <peter1138> Paypal take fees, yes...
12:14:30  <orudge> PayPal's fees appear to be about 3.4% + 20p, for UK payments at least
12:14:39  <orudge> PayPal is the most convenient way of us organising this, however
12:14:50  <orudge> a few people are donating via bank transfer, however
12:14:54  <orudge> those won't show up for a few days, of course
12:15:03  <orudge> and one guy is sending a (British) cheque from New Zealand
12:15:07  <orudge> so that may take a little while
12:15:13  <hylje> snail mail
12:15:49  <orudge> if people were to donate more than £55,000, though, the fee goes down to 1.4% and 20p
12:16:01  <orudge> or 2.9% and 20p for £1,500.01 - £6,000, it seems
12:16:27  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
12:16:30  <Lachie> my nipples are hard.
12:16:36  <Lachie> hang on
12:16:37  <Lachie> wrong channel.
12:16:43  <Ailure> Get enough Money and Paypal get suspcious and closes your account
12:16:44  <orudge> lovely
12:16:44  <Ailure> :)
12:16:52  <orudge> Ailure: not happened so far, touch wood :p
12:17:21  <peter1138> £55,000 would get you a nice server...
12:17:30  <Ailure> Well it's relativtly small amounts, but I do recall that happening with some donation thing some website was running
12:17:46  <Ailure> just as when it ran most succefully, paypal decided to close the account and refused to give back the money
12:17:55  <orudge> well
12:18:02  <orudge> I remember hearing about such things, but they were for sites like Oink
12:18:03  <Brianetta> So PayPal are making £30 or so from us
12:18:06  <Ailure> Well
12:18:07  <orudge> which weren't necessarily entirely above board
12:18:13  <Ailure> It was massive amount of money too
12:18:27  <peter1138> Paypal isn't the law though, heh...
12:18:39  <peter1138> Or maybe they are. :o
12:18:44  <Ailure> It's not a real bank so they can get away with more things sadly.
12:18:45  <Brianetta> Ailure: They're regulated in Europe now, as a bank.
12:18:49  <Ailure> oh
12:18:51  <Ailure> they are
12:18:53  <Ailure> intresting
12:18:55  <Brianetta> Used to be the FSA, but now it's a BeNeLux one
12:19:09  <Roujin> say peter, were you the one more into gui things regarding CargoDest development?
12:19:23  <orudge> £315.98!
12:19:50  <Brianetta> Paypal are hearing a "ch-ching!" and seeing a green figure rise from Owen's account.
12:19:52  <Yorick> wow
12:20:09  <Brianetta> Income: £0.46
12:20:22  <orudge> well, income £0.88
12:20:28  <orudge> (20 - 19.12 = 0.88)
12:20:28  <hylje> someone should totally make an animation of that for the fundraiser page
12:20:36  <Brianetta> I was just using a random looks-right figure
12:20:39  <orudge> ah
12:20:39  <orudge> heh
12:20:54  <Ailure> [14:19] <Brianetta> Paypal are hearing a "ch-ching!" and seeing a green figure rise from Owen's account.
12:21:04  <Ailure> Imagine how annoying it would in real life if that happened for every transaction event
12:21:11  <Brianetta> Annoying?
12:21:16  <Roujin> Awesome!
12:21:16  <Brianetta> I'd be crying tears of joy
12:21:32  * peter1138 ponders adding that to his payment gateway.
12:21:44  <peter1138> Plug a soundcard into the servers...
12:21:48  <Ailure> Not if it's as loud as in the game
12:21:58  <Ailure> if you live next to a train station, you get deaf in no time :)
12:22:08  <Ailure> (assuming that the sound scales with distance ;P)
12:23:07  <hylje> peter1138: awesome
12:23:37  <Roujin> peter1138, did you do the route map for CargoDest?
12:23:51  <Ailure> Though it reminds me, that's actually possible with a augmented reality
12:24:12  <Roujin> ooh, me likes augmented reality
12:25:32  <Roujin> always dreaming of some display light enough to fit into glasses without being obstrusive or anything :)
12:25:54  <Brianetta>
12:25:54  <Brianetta> We're two thirds of the way there in less than a day. Feels good to be part of this crowd.
12:26:00  <Ailure> I just like the idea of mixing reality with virtual things, which can be really useful for some tasks :p
12:26:00  <Sacro> ooh
12:26:03  <Sacro> are we a crowd now
12:26:08  <Sacro> i didn't think we'd passed rabble
12:27:25  <peter1138> Roujin, yes.
12:27:34  <peter1138> Well, I borrowed it.
12:28:06  <Roujin> peter1138: I've got a small suggestion, why not make it toggleable like the town names?
12:28:10  <Sacro> hehehe
12:28:13  <Sacro> toggleable
12:28:27  <hylje> toggleable-able
12:28:45  <Roujin> oO
12:31:38  <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
12:31:58  <Roujin> like you can enable/disable drawing the town names over any of the map modes as a base
12:34:36  *** a1270 [] has quit [Remote host closed the connection]
12:35:11  <peter1138> Because then you couldn't have the cargo-type toggles.
12:35:44  <Eddi|zuHause> Ctrl+Click on a view button overlays that view ;)
12:35:46  *** flowOver [] has quit [Quit: Leaving]
12:36:48  *** orudge [~orudge@] has left #openttd []
12:36:50  *** orudge [~orudge@] has joined #openttd
12:36:50  *** mode/#openttd [+o orudge] by ChanServ
12:36:58  <Roujin> hmm true
12:38:11  <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)
12:38:37  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
12:40:53  <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.
12:41:05  *** lobster_MB [~michielbr@] has joined #openttd
12:43:47  <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..
12:44:27  <Roujin> or not at all
12:44:58  *** KritiK [] has joined #openttd
12:48:08  *** Prof_Frink [] has joined #openttd
12:48:42  *** Ammler is now known as Ammller
12:50:29  <dih> OpenTTD should do a case insensitive check on playernames
12:50:51  <dih> i.e. it's possible to have a client called 'fibble' and 'Fibble' and 'fibblE'
12:51:10  <hylje> FibbIe
12:51:21  <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
12:51:23  <Rubidium> dih: even then it can be fooled rather easily
12:52:07  <Kloopy> But it still makes sense to prevent people who -aren't- trying to abuse the system to be told the name already exists.
12:52:25  <dih> Rubidium: how?
12:52:27  <Rubidium> dih: 
12:52:40  <Rubidium> (ofcourse you need a proper font to see it)
12:52:50  <Yorick> ^^
12:53:09  *** Ammller is now known as Ammler
12:53:11  <dih> oeh
12:53:13  <FauxFaux> <-- any ideas how to avoid trains being retarded like that? (stable 0.6.2)
12:53:21  <Yorick> servers can also have empty names...
12:54:11  <dih> FauxFaux: that trains order is not to go through that station
12:54:21  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
12:54:25  <FauxFaux> It's so not.
12:54:52  <FauxFaux> This screenshot's from a previous game, unfortunately, haven't caught anyone do it this game.
12:55:15  <dih> the train is heading to another station, that is why it's doing that
12:55:26  <Yorick> dih: it has to be lost
12:55:26  <dih> at least that is what i have experienced
12:55:38  <Yorick> to show random behavior ;)
12:55:53  <dih> Rubidium: is there nothing that could in theory be dont with those nicks?
12:56:14  <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. :/
12:56:31  <Yorick> I think you could make them contain alphanumeric symbols only for a start
12:56:46  <FauxFaux> That's rather western-minded.
12:56:51  <dih> the asian clients will love you Yorick for that idea :-P
12:57:02  <Rubidium> FauxFaux: looks like FS#1473
12:57:05  *** Brainstorm [] has quit []
12:57:09  <Yorick> :)
12:57:17  *** Brainstorm [] has joined #openttd
12:57:46  <FauxFaux> :)
12:57:50  *** Brainstorm is now known as Guest1531
12:57:57  *** Guest1531 is now known as Brainstorm
12:58:07  <dih> Rubidium: a case insensitive check on nick names would already be a good start ;-)
12:58:13  *** DJNekkid_ [] has joined #openttd
12:58:17  *** DJNekkid_ is now known as DJNekkid
12:58:44  <DJNekkid> is callback 1D/Varaction2 type C6 compatible with extended bytes?
12:59:07  <Yorick> Rubidium: disallowing spaces in names would also be an idea
12:59:19  <dih> Yorick: that is not the problem ;-)
12:59:39  <Yorick> dih: trailing spaces are sometimes hard to spot...
12:59:57  * Rubidium ponders disallowing LIKE %yorick%
12:59:57  <dih> that again is something else
13:00:01  *** fjb [] has joined #openttd
13:00:13  <fjb> hello
13:00:16  <dih> Yorick: trailing spaces != spaces in general
13:00:38  <Yorick> leading spaces too
13:00:56  <Yorick> I don't care about other spaces too much
13:00:58  <dih> trim and ci check ;-)
13:01:40  *** fjb [] has left #openttd []
13:01:47  <Yorick> servers are allowed to have empty names?
13:02:28  *** fjb [] has joined #openttd
13:05:08  <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
13:05:42  <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.
13:05:53  <dih> well spotted Eddi|zuHause
13:06:07  <FauxFaux> (
13:06:13  *** devilsadvocate [~user@] has joined #openttd
13:06:19  <dih> but the combo should be fine
13:06:56  <dih> FauxFaux: you only have that screenshot or you have a save too?
13:07:16  <Yorick> basically I think the last_exit_red penalty does not count nicely if it is not the last signal on the trains path ;)
13:07:33  <FauxFaux> Don't have a save, I've never managed to get trains to do it in a controlled environment.
13:07:37  <Eddi|zuHause>
13:07:38  <Yorick> FauxFaux: try making the exit signal 2-way
13:08:03  <Eddi|zuHause> (i think it's the same problem)
13:08:43  <FauxFaux> The screenshots have a far less understandable junction in. :)
13:08:52  <Eddi|zuHause> situation: two trains waiting at the entrances, all platforms are full
13:09:23  <Eddi|zuHause> a train leaves from the left half, combo signal and both entrance signals go green
13:09:40  <Yorick> it is a different situation
13:09:40  <Eddi|zuHause> train from the right sees green entrance and combo signal, starts
13:09:52  <Eddi|zuHause> train from left sees green entrance signal, starts
13:09:58  <peter1138> DJNekkid: Varaction never uses extended bytes.
13:10:05  <Eddi|zuHause> train from right sees red combo signal, gets lost
13:10:10  <Eddi|zuHause> tadaa
13:10:14  <Eddi|zuHause> your stuck situation
13:10:17  <DJNekkid> peter1138: thats what i've thought :)
13:10:33  <FauxFaux> That's a nasty one, yeah, I see now.
13:10:40  <Yorick> the combo isn't needed
13:10:44  <peter1138> You have the byte/word/dword varaction2 type to achieve that.
13:11:16  <Ammler> FauxFaux: PBS would solve that :-)
13:11:49  <Eddi|zuHause> suggestion: don't have that combo connection there at all, have two separate entrances
13:12:13  <peter1138> Suggestion, build a bypass route...
13:16:29  <FauxFaux> Yeah, bypass would work, the combo connection is really useful though, as the load-balancing between lines is a pita. :p
13:17:20  <Eddi|zuHause> it certainly is, if you don't make it symmetrical ;)
13:19:16  *** Osai^zZz is now known as Osai
13:21:28  <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.
13:22:05  <Eddi|zuHause> i think it's which one can start up fastest, and among those, the one with the lowest ID
13:22:33  <Eddi|zuHause> a queueing system is a huge problem...
13:22:44  <Yorick> Eddi: just check the waiting time ;)
13:22:45  *** KillaloT [] has joined #openttd
13:23:10  <Yorick> but it would mean some performance loss
13:23:24  <Eddi|zuHause> Yorick: you still can't easily decide which trains are waiting for the same section to clear
13:23:37  <Yorick> iterating n^n times
13:23:50  <Eddi|zuHause> yeah... sure...
13:24:03  <hylje> really weak reservations
13:25:52  <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
13:29:04  <dih> trallalla
13:30:17  <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
13:30:29  <Yorick> dih: it seems like you're happy, right?
13:30:40  <Eddi|zuHause> because then, instead of the number of waiting trains, the number of moving trains is the size of the input
13:31:02  <Eddi|zuHause> for each unreservation, you need to check if a train registered as listener
13:31:03  <dih> Yorick: yes ;-)
13:31:36  *** Belugas [~belugas@] has left #openttd []
13:31:42  *** Belugas [~belugas@] has joined #openttd
13:31:42  *** mode/#openttd [+o Belugas] by ChanServ
13:31:57  * Yorick congratulates dih with <unknown reason>
13:33:34  <dih> lol
13:33:38  <dih> hello Belugas
13:34:17  <Yorick> hello Belugas
13:34:31  <Belugas> hi guys
13:36:28  <Sacro> <- wtf @ Fragster
13:36:32  <Sacro> since when was PBS unrealistic
13:36:42  <Sacro> yes, cos british signalling runs on AND/NOT/OR isgnals
13:38:13  <Ammler> what is more powerful then kill -9?
13:38:36  <Eddi|zuHause> init 0
13:38:37  <Ammler> (only hardware switch, I fear)
13:38:55  <Ammler> Eddi|zuHause: how does init 0 kill a process?
13:39:05  <fonso> init 0 kills all processes
13:39:07  <Eddi|zuHause> it shuts down the computer ;)
13:39:11  <Ammler> how?
13:39:14  <Yorick> try
13:39:32  <Ammler> if I do that, it will hang on that process for hours :-)
13:39:44  <fonso> it tries to kill them and if that doesn't work it shuts down without killing them
13:39:57  <Eddi|zuHause> init 6, if you want to reboot
13:40:15  <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)
13:40:35  <Sacro> Ammler: isn't kill -15?
13:40:55  <Eddi|zuHause> kill -9 is stronger than kill -15
13:41:03  <dih> Ammler: what process?
13:41:03  <Ammler> Sacro: that is something like "close"
13:41:09  <Sacro> oh right
13:41:18  <Sacro> oh is 15 SIGHUP
13:41:22  <Ammler> mount.ntfs...
13:41:23  <dih> yup
13:41:32  <dih> does it have a parent or a child?
13:41:35  * Sacro checks that his luggage is all there
13:41:41  <dih> is it a zombie?
13:41:42  <Sacro> Ammler: sounds like ntfs-3g (fuse)
13:41:49  <Ammler> Sacro: yep
13:41:53  <Sacro> rmmod fuse
13:41:59  <Ammler> but I do not need that windows drive :-)
13:42:30  <Ammler> ERROR: Module fuse is in use
13:42:31  <CIA-5> OpenTTD: glx * r14066 /branches/noai/src/squirrel.cpp: [NoAI] -Revert(r14065): wrong working copy
13:43:03  <Ammler> dih: how do I see that?
13:43:32  <dih> Ammler: ps -AH ?
13:43:34  <Ammler> I have 0 zombies, so not
13:43:51  <dih> glx: lol?
13:44:13  <dih> Ammler: perhaps rmmod has something like a -f option?
13:44:24  <Sacro> shuold do
13:44:42  <Sacro> right, bbl#
13:46:22  <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 ;)
13:46:48  <glx> dih: it's not funny
13:47:15  <ln> glx: also remember to declare end of discussion after not funny.
13:47:16  <dih> i did add a questionmark :-P
13:47:47  <dih> <- AWSOME!!!
13:48:13  <Yorick> not bad
13:48:54  <Eddi|zuHause> a little bit buggy
13:49:00  <Yorick> I don't like jquery
13:49:15  <Eddi|zuHause> the names don't always appear and disappear correctly
13:49:29  <Yorick> what names?
13:49:48  <Ammler> hmm, hardware switch did the job :P
13:50:10  <Ammler> but still strange :-)
13:53:40  *** Golfgeo [~ice@] has joined #openttd
13:53:42  <Golfgeo> Hi all
13:54:22  <Golfgeo> Although not nice I would like to force electric trains via a cheat. Anyone know how to do this?
13:55:04  <Eddi|zuHause> there's a "disable electric rail" switch, if that is what you want
13:56:09  <devilsadvocate> hi.. is there any way i can enable automatic vehicle renewal on a saved game?
13:57:15  <Golfgeo> Eddi, Well, thats not the thing I mean. I would like to disable steam and diesel locks...
13:57:37  <Golfgeo> crap.
13:58:06  <glx> Golfgeo: write a newgrf
13:58:15  <Golfgeo> Sorry for that last time, wrong window
13:58:23  <Golfgeo> *thing
13:58:37  <Golfgeo> glx: hmm, interesting :-)
14:01:00  *** mikl [] has quit [Quit: Leaving...]
14:01:57  <devilsadvocate> its getting a bit of a pain replacing about 150 vehicles every few years ... :(
14:02:50  <Brianetta> devilsadvocate: It's all in the options menu
14:02:56  <Brianetta> You want "configure patches!
14:02:58  <Brianetta> "
14:03:27  <devilsadvocate> Brianetta, i tried that. It seems to be resetting every time i actually start/load the game
14:03:41  <Brianetta> Yes.  Change it *after* you load the game.
14:03:49  *** Sacro_ [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has joined #openttd
14:03:54  <Brianetta> Click-hold the spanner for the menu.
14:04:03  <devilsadvocate> will do
14:04:22  <devilsadvocate> got it
14:04:23  <devilsadvocate> thanks :)
14:04:27  <Brianetta> (:
14:05:30  <devilsadvocate> now i can spend some time hunting down all the lost trains :P
14:06:06  * Brianetta disables breakdowns and servicing
14:06:20  <Brianetta> My networks have only one depot
14:06:29  <Brianetta> Usually quite an ornate piece of eyecandy staion surrounds it.
14:07:57  <devilsadvocate> ive got about 40 stations connected to each other
14:08:05  <devilsadvocate> the gridlocks are beautiful, sometimes
14:08:55  *** Sacro [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has quit [Ping timeout: 480 seconds]
14:09:27  <devilsadvocate> it was especially interesting converting the whole thing to maglev
14:10:13  <Eddi|zuHause> i have not done that in years
14:10:36  <Eddi|zuHause> it does not make any sense with most newgrf sets
14:10:40  <Brianetta> Maglev is ugly.
14:10:52  <Eddi|zuHause> plus, i rarely reach that stage anyway, with the daylength patch
14:11:05  <devilsadvocate> i havent used any newgrfs yet.. just re-found openttd recently
14:11:12  <Brianetta> I sometimes have one short maglev track around a town.
14:11:15  <devilsadvocate> i agree with ugly
14:11:27  <Brianetta> A whole network's asking a bit much, though.
14:11:48  <devilsadvocate> i can show you the saved file if you want :P
14:12:38  <devilsadvocate> they're expensive, but with passengers they seem to pay back for themselves with the speed
14:12:42  <Brianetta> Wouldn't do me much good, here at work
14:13:05  <devilsadvocate> ah, ok
14:13:18  <Brianetta>
14:13:23  <Brianetta> King of newgrf sets
14:13:36  <Brianetta> Everything Pikka touches is fabulous
14:13:49  *** Yorick [] has quit [Quit: Poef!]
14:13:57  <Eddi|zuHause> i like the DBSetXL more ;)
14:14:04  <Brianetta> You would (:
14:14:23  <Brianetta> A train doesn't quite look right without yellow ends, though
14:14:39  <dih> lol
14:15:05  <Eddi|zuHause> i never could get warm with the uk engines...
14:15:07  <dih> now that could only come from a brit
14:15:29  <hylje> daamn wankar
14:15:34  <Brianetta> I'm still not sure *why* yellow
14:15:38  <Brianetta> of all the colours
14:15:46  <Brianetta> Flourescent pink would be more visible
14:16:02  <hylje> a bit too visible
14:16:04  *** dvo [] has quit [Read error: Connection reset by peer]
14:16:07  *** divo [] has joined #openttd
14:16:29  * devilsadvocate is used to dull red engines
14:16:58  <devilsadvocate> oh, and they should be dirty, too. doesnt look like they're working oterwise
14:18:40  *** dlunch [~dlunch@] has joined #openttd
14:20:32  *** dvo [] has joined #openttd
14:20:32  *** divo [] has quit [Read error: Connection reset by peer]
14:21:50  <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...
14:21:52  <Tekky> ...list of listeners than to make a pathfinder call.
14:22:33  <Eddi|zuHause> yes, but you might end up making the lookup more often than the pathfinder call
14:22:49  <Eddi|zuHause> especially when trains are not waiting
14:23:38  <Tekky> yes, you certainly will. But a pathfinder call is about 10,000 times more expensive than a simple lookup :)
14:24:22  <Eddi|zuHause> well, then do it ;)
14:24:54  <Tekky> That is what I am working on :-) But I'm having trouble understanding YAPF, because it makes heavy use of C++ templates :-(
14:26:14  <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
14:26:33  <CIA-5> OpenTTD: rubidium * r14068 /trunk/src/console_gui.cpp: -Fix (r14056): MSVC doesn't support typeof.
14:27:35  <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.
14:28:59  <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.
14:29:19  <hylje> neat
14:29:35  <Eddi|zuHause> i don't think that will work, because you can have multiple signals per segment
14:29:46  <hylje> do you intend to also cache potential segments at forks?
14:30:24  <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:
14:30:55  *** dlunch_ [~dlunch@] has joined #openttd
14:31:10  <Tekky> hylje: I define a track segment as a stretch of track with no signals or switches(=forks) in between.
14:31:25  *** lobster_MB [~michielbr@] has joined #openttd
14:31:42  <Tekky> This should be the base unit for PBS reservations.
14:32:10  <Tekky> Instead of individual track pieces.
14:33:10  <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.
14:33:40  <hylje> so it's not 1:1
14:33:57  <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
14:34:06  *** Mchl [] has joined #openttd
14:34:08  <Tekky> Yes, I am thinking of keeping YAPF segments and defining sub-segments for PBS reservations.
14:34:21  <Mchl> hello
14:34:32  *** dlunch [~dlunch@] has quit [Ping timeout: 480 seconds]
14:35:06  <Eddi|zuHause> good luck with that ;)
14:36:01  <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.
14:38:32  <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
14:40:19  <peter1138> Sacro_, best quote ever :D
14:42:49  <Tekky> Eddi: What you say "segment", do you mean "YAPF segment" or what I call "sub-segment"?
14:43:11  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
14:43:30  <Tekky> Eddi: Ah, my above question is irrelevant.... just a moment....
14:43:36  <Eddi|zuHause> doesn't matter...
14:44:51  <Tekky> Eddi: Just a moment, let me make a screenshot..... normally I upload files to RapidShare, is there a better place for uploading screenshots?
14:45:50  <Eddi|zuHause> imageshack?
14:47:49  * Belugas refuses to open the url upper mentioned containing the "realistic" key word
14:47:53  <Belugas> blasphemy!
14:48:02  <peter1138> YAPF segments end at junctions, don't they?
14:48:17  <peter1138>   Comment by Antonio (Fragster) - Friday, 11 January 2008, 13:50 GMT   —  Edit  —  Delete
14:48:20  <peter1138> I think, that it would be great alternative for PBS, which is very unrealistic
14:48:22  <Eddi|zuHause> Belugas: it does not say the r-word, it says the un-r-word
14:48:23  <peter1138> Just for Belugas :D
14:49:00  <Tekky> Eddi: thx, I will try imageshack
14:49:39  <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)?
14:51:43  *** fjb [] has quit [Quit: Leaving.]
14:52:47  <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.
14:53:08  <CIA-5> OpenTTD: rubidium * r14069 /trunk/src/ (fileio.cpp misc_gui.cpp querystring_gui.h): -Fix: silence MSVC 64-bits compile warnings.
14:53:44  <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.....
14:53: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
14:54:17  <peter1138> It's best not to save things that can be recreated.
14:54:44  *** dlunch_ [~dlunch@] has quit [Remote host closed the connection]
14:55:00  <Tekky> well, the reservation information will be smaller, if it is stored on a per-segment basis instead of a per-trackpiece-basis....
14:55:23  <Eddi|zuHause> there can be lots of segments
14:55:54  <Eddi|zuHause> especially if people place signals on every tile...
14:56:07  <peter1138> Or a lot of crossing track.
14:56:33  <Eddi|zuHause> really, i think creating a new pool is the better idea
14:56:47  <peter1138> How would you reference it?
14:57:04  *** fjb [] has joined #openttd
14:57:13  <Tekky> Yes, if people place a lot of crossing track, it would indeed be a problem :-(
14:57:19  <Eddi|zuHause> the existing "reserved" bit will only mean "there is a pool item for these coordinates"
14:57:59  <peter1138> What reserved bit?
14:58:21  <Eddi|zuHause> the yapp track reservation status bits?
14:58:24  *** dvo [] has quit [Read error: Connection reset by peer]
14:58:31  *** divo [] has joined #openttd
14:59:19  <Belugas> what index will be used to access the pool?
14:59:36  <Eddi|zuHause> (tileid, trackbit)?
14:59:41  <Sacro_> peter1138: ?
14:59:51  <peter1138> Sacro_, unrealistic PBS guy
14:59:58  <Belugas> pool index needs to be incremental
15:00:12  <Belugas> i.e.: cannot be forged
15:00:21  *** Sacro_ is now known as Sacro
15:00:28  <Sacro> peter1138: indeed
15:00:52  <Eddi|zuHause> hm... that makes it a little bit more difficult...
15:01:34  <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...
15:02:00  <peter1138> (The idea is to reserve a whole segment with one flag instead of having to reserve each tile)
15:02:09  <peter1138> I don't think it would offer much performance benefit.
15:02:45  <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...
15:03:00  <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
15:04:05  <Eddi|zuHause> especially if some reservations need to store the train id that made the reservation, and that can be multiple
15:04:06  *** Doorslammer [] has quit []
15:04:41  <peter1138> Why would you need to store the 'train id'?
15:04:59  <peter1138> Following the reservation back to a vehicle is not that complicated.
15:05:54  <peter1138> Type of reservation... that I don't understand, but you only need 2 bits to flag a different type.
15:05:55  <Eddi|zuHause> it is, if multiple trains are allowed to reserve the same trackbit (for really weak lookahead reservations)
15:07:01  <peter1138> Store a marker in the vehicles and follow all paths...
15:07:33  <Eddi|zuHause> "all paths" might be the whole map in some cases...
15:07:43  *** Purno [] has joined #openttd
15:08:36  <peter1138> That's a stupidly long reservation.
15:08:39  *** fonso [] has left #openttd [Kopete 0.12.7 :]
15:10:40  <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
15:11:11  <Sacro> @seen Bj
15:11:12  <DorpsGek> Sacro: I have not seen Bj.
15:11:14  <Sacro> @seen Bjarni
15:11:14  <DorpsGek> Sacro: Bjarni was last seen in #openttd 15 hours, 51 minutes, and 46 seconds ago: <Bjarni> goodnight
15:11:51  *** divo [] has quit [Read error: Connection reset by peer]
15:12:12  <Belugas> Eddi|zuHause, seems like a better built rail system might be better suited for the task
15:12:22  <Belugas> personally speaking
15:12:43  <Eddi|zuHause> i was speaking hypothetically ;)
15:13:03  <Belugas> welll... isn;t it the goal the new proposal is aimed at?
15:13:09  <Belugas> -is
15:13:12  <Belugas> -l
15:13:17  <Belugas> +work@work
15:13:47  *** david [] has joined #openttd
15:14:20  <Eddi|zuHause> depending on which proposal you mean, there are different aims that might be slightly overlapping
15:14:20  *** david is now known as Guest1543
15:15:06  <Eddi|zuHause> people sometimes have difficulties following my suggestions, because i think at least 3 steps ahead ;)
15:15:23  <Tekky> Eddi: I have uploaded an image with 6 track segments, I call them 1R, 1L, 2R, 2L, 3R, 3L. Here is the link:
15:16:40  <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.
15:16:47  <Tekky> 2r = 2R
15:17:21  <peter1138> Signalless operation? :p
15:17:48  <Sacro> for tvg
15:18:20  <Eddi|zuHause> Tekky: the problem is, the segments 1L and 2L overlap on the switch tile
15:18:26  <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
15:18:50  <Eddi|zuHause> so when a train reserved segment 1L, you cannot be sure if it already left the switch tile or not
15:19:10  <Eddi|zuHause> so a second train coming from 3L cannot reserve 2L
15:19:10  <Tekky> peter1138: So we are not talking about signals.
15:19:48  <Eddi|zuHause> Tekky: for this to work, each trackbit on the switch tile must be a separate segment
15:20:30  <Eddi|zuHause> which at least doubles the number of segments
15:20:54  <Tekky> Eddi: If the train that reserved 1L has not left the switch yet, it will still have a reservation on 2L.....
15:21:20  <Eddi|zuHause> no... the train never touches 2L
15:22:03  <Tekky> a train touching a switch will always have at least two segments reserved....
15:23:01  <Eddi|zuHause> train reserved 3L and 1L, but the reservation of 3L will be removed once the last wagon entered the switch tile
15:23:18  <Eddi|zuHause> then only 1L is reserved, but the train is still on the switch
15:23:23  <Tekky> reservations are always in a certain direction.... if a train wants to reserve 1R, it must also reserve 2R and 3L
15:23:28  <Eddi|zuHause> the next train wants to reserve 3L and 2L
15:23:49  <Tekky> However, a train may reserve 1L without making any further reservations.
15:23:50  <Eddi|zuHause> that is not how reservations are done
15:24:35  <Eddi|zuHause> PBS makes reservations for the trackbits it intends to go on, not the ones it crosses
15:25:10  <Eddi|zuHause> another train may not reserve a trackbit if a crossing trackbit is already reserved
15:25:43  <Tekky> well, indirectly, both do the same thing :-) The result is the same.....
15:26:03  <Eddi|zuHause> if you substitute "trackbit" for "segment", this will have the effect i described
15:26:08  *** frosch123 [] has joined #openttd
15:26:45  <Brianetta> Wow.
15:26:52  *** Reemo [] has joined #openttd
15:28:12  <Eddi|zuHause> of course, your model might work better if you introduce "using" and "blocking" reservations
15:28:19  <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.
15:29:28  <Brianetta> Old (NPF) PBS would recalculate reservations en route
15:29:50  <Brianetta> So your train could be on a shared block, and suddenly decide to cross behind another train
15:30:01  <Brianetta> It was pretty cool
15:30:25  <peter1138> But buggy...
15:30:34  <Tekky> and unrealistic :)
15:30:40  <peter1138> Hah
15:31:00  <Brianetta> (:
15:31:08  * Brianetta likes realism
15:31:12  <Brianetta> Magic brakes.
15:31:21  <Brianetta> Every train grows them one tile before a red signal.
15:32:38  <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.
15:32:55  <orudge> £370.10
15:33:22  <Tekky> can't wait for the new dedicated server :-)
15:33:22  <Brianetta> orudge: It's fan-bloody-tastic.
15:33:34  *** lobster_MB [~michielbr@] has joined #openttd
15:33:39  <Belugas> amazing, i would say :)
15:34:30  <orudge> plus 3 donations via bank/cheque to come, and a handful of PayPal eCheque payments to clear
15:34:30  <Rubidium> seems to go even better than the last one
15:34:51  <orudge> well, last time we asked for £250 or so, and got £312, as people donated quicker than I could update the page
15:35:25  <Rubidium> in 20 hours; the fundraiser is now also open for ~20 hours
15:35:40  <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.....
15:35:55  * Sacro feels an urge to donate
15:36:16  <orudge> Sacro: cash only, please, no sperm
15:36:24  <Eddi|zuHause> it might work out, but i'm still not convinced of reusing the yapf cache
15:36:56  <Sacro> orudge: cash?
15:37:03  <Sacro> you going to come collect?
15:37:11  <orudge> well, cash as in money
15:37:30  <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.
15:38:56  <Tekky> Eddi: It would be impossible to store all of these different reservation types in the map array, so we need an external graph.
15:38:59  <Eddi|zuHause> yes. you explained that before
15:42:38  <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
15:42:40  <Tekky> lso cleared. For this, all reservations require reference counting.
15:42:59  <Tekky> a lso = also
15:43:44  <Tekky> Eddi: such reference counting would certainly not fit in the map array :)
15:44:23  <Eddi|zuHause> you're beating a dead horse... i understand very well why the map array reservation is not extendable
15:44:44  * Belugas pats poor map array
15:45:10  <Eddi|zuHause> my questioning concerned reusing the yapf cache vs. creating a separate reservation cache
15:45:28  <Eddi|zuHause> because the yapf cache does not need storing, the reservation cache does
15:45:47  * Rubidium wonders how useful the YAPF cache is for NPF or OPF
15:45:49  <Eddi|zuHause> plus, like you said, yapf does not care about signals
15:48:05  <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...
15:48:07  <Tekky> ...this "blocking reservation" will be cleared.
15:49:00  <CIA-5> OpenTTD: rubidium * r14070 /branches/noai/ (12 files in 4 dirs): [NoAI] -Fix: silence MSVC 64 bits warnings.
15:49:21  <Tekky> Eddi: Well, the YAPF cache and the reservation data is very similar, because both are graphs of the track layout.
15:50:13  <Tekky> Eddi: Therefore, it makes sense to combine them, I believe.
15:50:31  *** Gekz [] has joined #openttd
15:50:42  *** Gekz [] has left #openttd []
15:50:44  <Rubidium> Tekky: but remind yourself of the fact that NPF and OTP/OPF do not use the YAPF cache
15:51:00  *** Gekz [] has joined #openttd
15:51:02  <Eddi|zuHause> but they are different for exactly the reasons mentioned: signals play a role, persistency, using the YAPF cache without using yapf
15:51:11  <Eddi|zuHause> these are all reasons to not combine them
15:51:37  *** Farden123 [] has joined #openttd
15:53:12  <Tekky> Eddi: Ok, the YAPF cache only has to be persistent for track segments in PBS blocks.....
15:53:34  <Eddi|zuHause> now you're getting silly...
15:54:33  <Brianetta> All signal blocks are PBS blocks in my games.
15:54:49  <Noldo> do the original pathfinding methods for rvs, trains and ship share any code?
15:55:11  <Rubidium> yes
15:55:40  <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?
15:56:40  <Tekky> Eddi: That seems like an obvious statement to me, or am I mistaken?
15:57:56  <Tekky> Brianetta: Yes, I also exclusively use YAPP signals, because standard signals and YAPP signals do not mix very well, I'm afraid :-(
15:58:35  *** Farden [] has quit [Ping timeout: 480 seconds]
15:58:36  <Rubidium> they work fine for me
15:58:45  <Sacro> Tekky: mix fine here
15:58:53  <Sacro> using all PBS is unrealistic
15:59:15  <dih> my BUNNY is over the ocean....
15:59:17  <Belugas> mmh... so i should start doing that
15:59:25  <Noldo> dih: what?
15:59:32  <Brianetta> I find that they mix fine; I just can't be bothered to switch signal types.
15:59:33  <dih> my BUNNY is over the sea
15:59:43  <Brianetta> There's no specific advantage to having regular signals.
16:00:18  <Sacro> Brianetta: less CPU usage
16:00:20  <Brianetta> Sacro: Unrealistic?  Justify that claim.
16:00:24  *** fjb [] has quit [Quit: Leaving.]
16:00:51  *** ProfFrink [] has joined #openttd
16:00:59  <Sacro> Brianetta: in UK signalling you tend to have automatic signals where there is no junction
16:01:02  <Eddi|zuHause> along a straight track, "realistic" would be combo signals
16:01:20  <Eddi|zuHause> the ones from my suggestion
16:01:50  <Eddi|zuHause> i.e. a main signal and an advance signal combined each km
16:01:50  <Brianetta> Sacro: Nevertheless, junctions are all over the place (normally crossovers)
16:02:03  <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...
16:02:05  <Tekky> ...with me, so I exclusively use YAPP signals where automatic train reversal can be deactivated.
16:02:08  <Brianetta> and all UK signals I have seen remain red until a train is given permission to proceed
16:02:10  <Sacro> Brianetta: true
16:02:16  <Brianetta> which is exactly what advanced signals do
16:02:28  <Sacro> a lot do clear to green when the line is clear
16:02:32  <Sacro> esp on the ECML
16:03:04  <Brianetta> Tekky: Always join regular and PBS with one-way PBS
16:03:56  <Eddi|zuHause> Brianetta: does not prevent the trains from turning around
16:03:58  <Brianetta> Sacro: No; they're green because a train's coming
16:04:20  <Brianetta> Eddi: That's a problem with regular signals anyway
16:04:28  <Sacro> Brianetta: if a signal has a black plate with a white line then it will clear to green when the line is clear
16:05:40  <Sacro> however some have an emergancy button to hold them at red
16:05:46  <Eddi|zuHause> Sacro: but then you can't have bidirectional traffic on the track
16:05:57  <Sacro> Eddi|zuHause: not a lot of the UK is equipped for bidi
16:06:04  <Brianetta> All the ECML roads up here are bi-directional
16:06:33  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
16:06:33  *** ProfFrink is now known as Prof_Frink
16:06:38  <Sacro> Brianetta: are you sure?
16:06:43  <Sacro> i didn't think any of the ECML was
16:06:45  <Brianetta> Sacro: yes.
16:07:03  <Brianetta> I've been held up by a freight train going our way, that broke down when it switched in front of us.
16:07:15  <Sacro> that's not bidi
16:07:25  <Brianetta> It was on the other road.
16:07:37  <Brianetta> It was travelling south, same as us, toward york.
16:07:43  <Sacro> could just be up slow, up fast, down fast, down slow
16:07:53  <Brianetta> It switched to our side, but by the time we got to where it was, it had conked out.
16:07:53  <Sacro> it might have switched from slow to fast
16:07:59  <Brianetta> There are only two roads
16:08:21  <Sacro> you might have been authed for a wrong side manouvre
16:08:35  <Brianetta> Or the freight was.
16:08:42  <Brianetta> They're bidi, though
16:08:49  *** Farden123 is now known as Farden
16:09:18  <Brianetta> My best man used to manage regional maintenance when Balfour Beatty had the contract from Railtrack
16:10:04  <Brianetta> Trains have even been known to race each other (:
16:10:31  *** Gekz [] has quit [Ping timeout: 480 seconds]
16:10:45  <Brianetta> One driver, doing so, missed three detonators.  Luckily he also missed the crew working on the line further down.
16:11:05  <peter1138> "Whoops"
16:11:06  *** devilsadvocate [~user@] has quit [Quit: Leaving]
16:11:10  <Brianetta> Yes.
16:11:16  <Brianetta> Think he's no longer driving.
16:11:55  <Tekky> is it true that a call to NotifyTrackLayoutChange(TileIndex tile, Track track) invalidates the entire YAPF cache?
16:12:18  <Eddi|zuHause> "three detonators" being the "emergency stop" signal?
16:12:37  <Brianetta> Yes.  Well, even one is.  Three is to make sure it's noticed.
16:12:53  <Brianetta> If your wheels go bang, you stop.
16:13:00  <Eddi|zuHause> Tekky: yes, that's exactly what the function is supposed to do
16:13:09  <Sacro> ooh
16:13:14  <Sacro> plans for grade seperation at hitchin
16:13:52  <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.....
16:16:04  <Tekky> Eddi: I guess I must change this, too :)
16:16:30  <Tekky> Hehe, there is so much stuff in OpenTTD that I would like to change. ;-)
16:16:57  *** trainboy2004 [] has joined #openttd
16:17:05  *** trainboy2004 [] has quit []
16:17:15  *** TinoM [] has joined #openttd
16:19:31  <Eddi|zuHause> really, i mean it... combining the YAPF and reservation caches is a bad idea...
16:21:18  <Tekky> You may be right... I am currently studying the YAPF cache to see exactly how it is implemented....
16:22:12  <peter1138> The YAPF cache that is not used for NPF or OPF...
16:22:14  <peter1138> Still not...
16:22:38  <Belugas> [12:16] <Tekky> Hehe, there is so much stuff in OpenTTD that I would like to change. ;-)  <-- start a fork
16:22:41  <Belugas> provide patches
16:22:46  <Belugas> do something!
16:22:53  <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.....
16:25:06  <Tekky> Belugas: yes, I am doing something, I am currently studying YAPF in detail :-)
16:26:31  <Belugas> you are braver then me
16:26:39  <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.
16:26:40  <Belugas> or having a lot more time then me
16:27:53  <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:
16:29:13  <frosch123> and both ttdp's and ottd's are in parts based on it :)
16:29:21  <frosch123> +pbs
16:30:17  <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 :(
16:30:42  <Tekky> and also a train scheduler/prioritizer would have to be implemented.....
16:32:01  <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.
16:33:17  <Eddi|zuHause> i just feel the urge to throw shunting reservations into the pool ;)
16:33:51  <Belugas> do it do it do it
16:33:56  <Brianetta> Tekky: You're going to have to do a lot of work to figure out which train gets to strengthen its reservation.
16:34:34  <Brianetta> I just want to see express orders (:
16:34:55  * frosch123 wonders whether he should bother about preserving vehicle news when vehicles are sold and bought by autoreplace...
16:35:00  <Tekky> Yes, I know, and it will be very CPU-intensive.... therefore, the track layout will have to be heavily cached......
16:35:43  *** Bjarni [] has joined #openttd
16:35:46  *** mode/#openttd [+o Bjarni] by ChanServ
16:36:26  <Sacro> Bjarni!
16:37:13  <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.
16:38:09  <Tekky> a more intelligent train conflict resolution scheme can be developed later.....
16:38:24  <Brianetta> What determines priority?
16:38:35  <Brianetta> Also, what determines conflict?
16:38:41  <Tekky> I guess a train's priority level should be set in the train's orders....
16:39:19  <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"
16:39:21  <Bjarni> you mean like you can set a train with full load to have higher priority than the returning empty ones?
16:39:39  <Brianetta> Bjarni: My take was to have an order modifier, so yes
16:40:00  <Brianetta> An "express" button along with non-stop and full load and so on
16:40:17  <Eddi|zuHause> a train's reservation priority should decrease with the amount of signals passed
16:40:27  <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.
16:40:31  <Brianetta> All it would do, very simple, is reserve an additional path, if possible.
16:40:43  <Brianetta> First come, first served.
16:41:01  <Brianetta> Im fine with my unimportant trains not looking ahead.
16:41:06  <Brianetta> It saves memory and CPU.
16:41:07  <Tekky> Bjarni: yes, a train will full load should normally be set to also have a higher priority than empty trains.
16:41:11  <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
16:41:42  <Brianetta> That could work, Eddi
16:41:43  <Eddi|zuHause> the priority of the reservation would increase when the train approaches
16:41:55  <Brianetta> but it's the current order that should have priority, not the train
16:41:56  <Tekky> not bad ideas....
16:42:07  <Eddi|zuHause> yes, priorities should be order based
16:42:09  <Brianetta> and priority shouldn't be tied to "non-stop" or "full load"
16:42:13  <Brianetta> It should be separate
16:42:21  <Brianetta> My coal trains full load, and my passenger trains don't
16:42:28  <Brianetta> but I never want my coal trains muscling through
16:42:52  *** trainboy2004 [] has joined #openttd
16:43:12  *** trainboy2004 [] has left #openttd []
16:43:41  <Tekky> anyway, all of these ideas require in my opinion a rewrite of the way reservations are stored....
16:43:56  <Eddi|zuHause> but it's relatively independent from advance signals
16:44:11  <Brianetta> yes
16:44:19  <Eddi|zuHause> because those just change the way "strong" reservations are made
16:44:23  <Brianetta> advance signals don't really excite me...
16:44:38  <Tekky> I disagree. There is no point in having lookahead reservations with standard non-YAPP signals, in my opinion.
16:44:50  <Brianetta> Tekky: My original proposal requires no changes to storage
16:45:02  *** fjb [] has joined #openttd
16:45:05  <Eddi|zuHause> Tekky: advance, not advanced ;)
16:45:08  <Bjarni> we have free bits in the order struct
16:45:19  <Tekky> Eddi: Oh, I thought you just made a typo :)
16:45:22  <Brianetta> an order marked "express" simply means "try to reserve more track"
16:45:31  *** welshdra-gone is now known as welshdragon
16:45:34  <Brianetta> Eddi: Can also call them "distant signals"
16:45:37  <Bjarni> actually we have 16 in a row. A single byte should be enough
16:45:50  <Eddi|zuHause> Brianetta: that could work ;)
16:46:18  <Sacro> i want advance signals
16:46:31  <Brianetta> Sacro: Terminology (:
16:46:52  <Bjarni> Sacro: you should describe what you want it to do in the game
16:47:06  <Eddi|zuHause> the problem is "advance" is too similar to "advanced", people will always confuse those
16:47:08  <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.
16:47:09  <Sacro> Bjarni: if it is on then a train should slow down
16:47:09  <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 :(
16:47:22  <Sacro> Tekky: 10?
16:47:25  <Sacro> we aren't germans
16:47:40  <Brianetta> 10 is a binary number
16:47:44  <Tekky> lol
16:48:05  <Bjarni> here an advance signal can have 3 different states
16:48:48  <Brianetta> Sacro: I say worry about distant signalling only when a train loses its magic brakes.
16:49:00  <Sacro> Brianetta: yes, true
16:49:06  <Bjarni> "reduced speed (including stop)", "full speed" and "full speed all the way though the station (this is used at entrances to stations)
16:49:08  <Sacro> Bjarni: here it is two
16:49:11  <Sacro> it is on. or off
16:49:13  <Brianetta> End of line, red signal, backwards one-way signal.  All of these make a train stop magically.
16:49:34  <Brianetta> Stop that happening, and then we'll need distant signals.
16:49:44  <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.
16:49:53  <Brianetta> Actually, even then it'll be optional, since a train cean see the next signal even if it's around a bend.
16:50:41  <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.
16:50:42  <Eddi|zuHause> Tekky: the solution to that is forcing the train to reserve more signal blocks ahead
16:50:54  <Brianetta> Usually because the red one was in a forest, or around a cliff.
16:51:17  <Sacro> Brianetta: nope, distants where always used
16:51:26  <Brianetta> Sacro: When they were invented, no
16:51:27  <Sacro> if you can't see the main then you have a repeater
16:51:38  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
16:51:49  <Eddi|zuHause> it could also be to make a speed limit of 160km/h on conventional rail, and add a special "high speed" railtype
16:51:58  <Brianetta> distant === repeater, originally
16:52:04  <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"?
16:52:06  <Sacro> yeah, but not now
16:52:11  <Sacro> Bjarni: oh right
16:52:13  <Sacro> no
16:52:15  <Brianetta> Sacro: The game starts well before now (:
16:52:16  <Sacro> on = red
16:52:18  <Sacro> off = green
16:52:30  <Tekky> Eddi: Hmmmm, nah, that may be a bit too specific to German Railway......
16:52:33  <Sacro> Brianetta: i don't go further back than 1950 :p
16:52:37  <Sacro> no trains existed before then
16:52:48  <Brianetta> My server starts in 1920
16:53:02  <Brianetta> I'd have it in 1890 if there were decent trains around
16:53:14  <Tekky> Eddi: Should the high-speed railtype also use signals?
16:53:21  <Brianetta> except the towns look a bit over-modern
16:53:33  <Sacro> Tekky: well tgv doesn't
16:54:19  <Tekky> Eddi: I mean distant signals? Or should the train's speed be controlled directly by Centralized Traffic Control?
16:54:33  <Tekky> Eddi: Of course, main signals must always be placed....
16:55:10  <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
16:55:34  <Bjarni> the crossing signal is slowly being replaced by a new type with lights for all states
16:55:54  <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
16:56:05  <Bjarni> and I don't think the stop light is a safety device
16:56:07  * peter1138 ponders running a network game...
16:56:23  <Eddi|zuHause> Tekky: but i have no idea how to properly include that in the game
16:57:41  <Bjarni> Eddi|zuHause: I know that system and I don't like it
16:58:03  <Bjarni> basically it messes up even more when the system goes down and they have to rely on external signals
16:58:52  <Bjarni> or a train without a working reading of the "LZB" uses way more room on the tracks since it takes up more blocks
16:59:06  <Bjarni> but... why implement this in the game?
16:59:07  <Eddi|zuHause> i'm speaking from a gameplay perspective, i don't think it will fit...
16:59:48  <Bjarni> bbl
17:01:31  *** Frostregen [] has joined #openttd
17:07:45  <Brianetta> Going home.
17:07:46  *** Brianetta [] has quit [Quit: TschÌß]
17:07:55  <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.
17:08:53  <Tekky> A player should be forced to also place distant signals, otherwise all trains are limited to a speed of 40km/h (=25mph)
17:09:09  <Tekky> in order to always be able to brake in time.
17:09:19  <orudge> £396.03 so far
17:09:23  <orudge> not much more to go
17:09:45  <Tekky> yay :)
17:11:03  *** fjb [] has left #openttd [Leaving.]
17:12:56  <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.
17:13:02  <Tekky> signasl = signals.
17:14:08  <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
17:14:11  *** lobster_MB [~michielbr@] has joined #openttd
17:14:45  <Eddi|zuHause> slowing down can be done by a precalculated braking curve, like with stations...
17:17:50  <Tekky> Eddi: What you suggest would only be possible if there are signals at regular intervals.....
17:18:19  <Tekky> What if the only signal on the track is an entry signal for a station?
17:19:30  <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?
17:19:53  <Eddi|zuHause> no, it should run the red light, and cause crashes
17:20:50  <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.
17:21:01  <Tekky> there = the
17:21:45  <Eddi|zuHause> you as the track developer are in charge to put distant signals before the main signals
17:22:38  <Eddi|zuHause> of course, switching off the "emergency brake" would be a difficulty option
17:22:38  <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.
17:23:32  <Eddi|zuHause> Tekky: the train should check if there is a distant signal when reserving the track?
17:24:40  <Eddi|zuHause> it might be possible...
17:24:40  *** fjb [] has joined #openttd
17:24:43  *** Yorick [] has joined #openttd
17:24:43  <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.
17:25:14  <Eddi|zuHause> Tekky: the main signal might be reachable from different distant signals
17:25:59  *** fjb [] has quit [Quit: Leaving.]
17:26:10  *** fjb [] has joined #openttd
17:26:49  <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
17:27:07  <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.
17:27:45  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
17:29:44  <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.
17:30:23  <Eddi|zuHause> not the train, the reservation routine... TryPathReserve()
17:31:44  <Eddi|zuHause> it would then return a status info instead of a bool
17:32:07  <Eddi|zuHause> this status struct would have a "slow" flag, which sets the speed limit to 40km/h
17:34:37  *** Fuco [] has joined #openttd
17:37:41  <Tekky> I prefer to cache this information in the track segment, you know how much I like caching information. :-)
17:39:05  *** Brianetta [] has joined #openttd
17:46:16  <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
17:46:37  <Eddi|zuHause> it may pass a lot of track segments before getting to the one with the signal
17:47:40  <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
17:48:23  <Eddi|zuHause> you might want to consider if that would be more effort than storing it in the train
17:49:08  *** lobster_MB [~michielbr@] has joined #openttd
17:49:28  <DJNekkid> could anyone see the last post on this thread?
17:49:47  <orudge> as in your post?
17:50:30  *** Roujin [] has quit [Ping timeout: 480 seconds]
17:51:37  <DJNekkid> as in my post :)
17:52:05  <orudge> target exceeded!
17:52:07  <orudge> £494.30 :)
17:52:23  <Wolf01> lol 1 day!!!
17:52:31  <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
17:52:44  <orudge> Wolf01: not even that
17:52:53  <orudge> 21 hours :)
17:52:55  <Brianetta> So, more RAM?
17:52:56  <Wolf01> :D
17:53:01  <orudge> well
17:53:02  <Brianetta> Beefier CPU?
17:53:11  <Brianetta> What does a compile farm benefit from?
17:53:33  <Wolf01> lots of GB to share p0rn and w4r3z!!!!
17:53:56  <Rubidium> Brianetta: beefier? The offer already has a quad core xeon ;)
17:54:04  <Wolf01> masked of ottd savegames
17:54:10  <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
17:54:43  <Yorick> I think he won it
17:54:54  <Yorick> and :)
17:54:56  <Brianetta> Rubidium: More gigahurts
17:55:15  <Yorick> already exceeded
17:55:24  <Rubidium> that'd cost much much more per month
17:55:30  <Rubidium> as in double the amount
17:55:36  <Brianetta> Rubidium: CPU speed?
17:55:45  <Rubidium> cause you need to go to another "package"
17:55:50  <Brianetta> oh
17:55:58  <Brianetta> This won't be your property, then?
17:56:04  <Rubidium> nope
17:56:04  <orudge> this one isn't
17:56:06  <Brianetta> Ah.
17:56:08  <orudge> we looked into a variety of options
17:56:12  <Brianetta> I thought it'd be like my own colo
17:56:13  <orudge> including colocation (which the forums do)
17:56:15  <Brianetta> where the kit ismine
17:56:18  <Brianetta> I rent a slot ina  rack
17:56:24  <orudge> but this is an offer that really beats what we could have done ourself
17:56:46  <Brianetta> I suppose if it's leased then if parts go pop, they sort it out
17:56:57  <Rubidium> exactly
17:57:30  <Eddi|zuHause> 2x500GB HD <- i assume that's Raid 1?
17:57:30  <orudge> yes
17:57:55  <Eddi|zuHause> so 500 useable and 500 mirrored
17:58:16  <orudge> effectively
17:58:50  <Yorick> Eddi: no, the other way around :)
17:59:17  <FauxFaux> XP in qemu doing VS builds, right?
17:59:53  <Rubidium> rather virtualbox as it's quicker
18:00:07  *** Mchl [] has quit []
18:01:38  <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
18:01:42  <orudge> average donation was £9.51
18:01:47  <orudge> there were 52 in total
18:01:57  <orudge> 31 of which were in euros
18:02:05  <Fennec> that was fast.
18:02:10  <orudge> 8 in US dollars
18:02:11  <orudge> and the rest in GBP
18:02:16  <Sacro> why virtualbox
18:02:19  <Sacro> why not mingw?
18:02:28  <orudge> mingw is what is currently used
18:02:34  <orudge> I'm not sure why virtualbox would want to be used, to be fair
18:02:38  <Yorick> Sacro: current compilefarm crosscompiles :)
18:02:39  <orudge> but I assume there's a reason
18:02:55  <Yorick> I'm not sure why VS would want to be used
18:03:15  <Rubidium> because we want to use the compile farm to make the release binaries too
18:03:25  <Sacro> Rubidium: mingw can't do that?
18:03:27  <Rubidium> and mingw doesn't support win64 (or at least didn't very recently)
18:03:42  <Rubidium> Sacro: mingw's binaries can't make crash reports
18:03:48  <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)
18:03:53  <orudge> Rubidium: does that rely on some sort of MSVC functionality?
18:03:59  <orudge> if so, what precisely?
18:04:12  <Rubidium> orudge: I've got absolutely no idea
18:04:13  <Sacro> x86_64-pc-mingw32
18:04:25  <orudge> Rubidium: heh, fair enough
18:04:42  <Rubidium> I only know that it doesn't work for mingw and does work for MSVC
18:05:00  <orudge> hmm
18:05:10  <Sacro> can you not install the msvc compiler under wine?
18:05:19  <orudge> Older versions work on Wine I think
18:05:22  <orudge> but I don't think the 200x ones do
18:05:37  <Sacro> orudge: not the IDE, the compiler
18:05:40  <Sacro> not sure what it is called
18:05:40  <orudge> yes
18:05:43  <orudge> that is what I'm referring to
18:05:49  <orudge> according to somebody, .NET-type things make it break
18:05:52  <Rubidium> Sacro: the compiler requires .net 3.5, which fails to compile under wine
18:05:54  <orudge> but I've not tried it myself
18:06:04  <Rubidium> and mono doesn't support .net 3.5 enough to support msvc
18:06:30  <Sacro> Rubidium: why does the compiler need .net 3.5 ><
18:06:38  <orudge> Ask Microsoft that one.
18:06:40  *** ecke [~ecke@] has quit [Quit: ecke]
18:06:45  <Rubidium> because it is fracking written (partly) in .NET
18:06:56  <orudge> we should port OpenTTD to Borland C++ or something exciting like that :D
18:07:03  <orudge> actually, I did try to build it with BCW back in the day
18:07:08  <orudge> back then, it would actually build
18:07:10  <orudge> these days, probably not
18:07:20  <Sacro> orudge: qbasic
18:07:27  * orudge wonders how Open Watcom is getting along
18:07:30  <Rubidium> go fix the DOS build, we NEED it ;)
18:07:31  <orudge> hmm, still v1.7a
18:07:40  <orudge> Rubidium: heh, maybe once I get other things done ;)
18:08:11  <Sacro> surely yiou can run the vs2005 compiler on less
18:08:18  <Sacro> it was before .net 3.5 came out
18:09:09  <peter1138> Pom te pom
18:09:41  <Rubidium> Sacro: 2005 needs .net 2.0, also doesn't work under wine nor mono as of a month ago
18:09:55  <Sacro> sigh
18:09:55  <Rubidium> it furthermore has problems with x64 when I last tried it
18:09:57  <Sacro> 2002?
18:10:14  <Rubidium> crashes on the source code
18:10:21  <Rubidium> 2003 doesn't understand enough of templates
18:10:27  <Sacro> sigh
18:10:35  <Sacro> i don't see why mingw doesnt' do the job
18:10:36  *** Progman [] has quit [Remote host closed the connection]
18:10:52  *** ecke [~ecke@] has joined #openttd
18:11:48  <Rubidium> Sacro: because it doesn't have crash reports
18:11:59  <Sacro> hmm, right
18:12:02  <Rubidium> which makes finding causes for bugs even harder
18:13:55  <DJNekkid> thanx eddie :)
18:13:57  <DJNekkid> and lakie :)
18:14:05  <Yorick> get it crash reports :)
18:19:20  *** stillunk1own [] has joined #openttd
18:19:21  *** stillunknown [] has quit [Read error: Connection reset by peer]
18:20:47  *** ecke [~ecke@] has quit [Quit: ecke]
18:22:59  *** Lenny [] has joined #openttd
18:23:30  *** Lenny is now known as Guest1571
18:29:52  *** Guest1571 [] has quit [Quit: Bye for now!]
18:36:05  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
18:45:20  *** mikl [] has joined #openttd
18:46:21  <Belugas> wow... fundraising seemed to be a real hit!
18:46:31  <DJNekkid> we (L) OTTD :)
18:46:51  *** Powerek38 [] has joined #openttd
18:46:51  <Eddi|zuHause> loathe?
18:46:53  <Belugas> if there are any donators in this humble assembly, let me express my gratitude :D
18:47:04  <Powerek38> hello
18:47:06  <Belugas> thanks a lot
18:47:14  <Belugas> holle
18:47:16  <Belugas> hrmm
18:47:17  <Belugas> hello
18:47:22  <Sacro> orudge: you have overflowed
18:47:24  <Prof_Frink> DJNekkid: Eat unicode! ♥
18:47:31  <Powerek38> does anyone has a link to a download of the newcargos file?
18:47:52  <Sacro> Powerek38: there are a fair few different newcargos
18:47:55  * DJNekkid takes a big bite
18:48:33  <Eddi|zuHause> Powerek38: that's a very old set, i recommend any of the various newer sets
18:48:45  <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
18:48:48  <Prof_Frink> DJNekkid: I wouldn't. ☠ It's poisonous.
18:49:01  <Sacro> Powerek38: so you need a vehicles newgrf :p
18:49:14  <Eddi|zuHause> Powerek38: then get the UKRS set from that same page
18:49:20  <DJNekkid> or 2cc ;);)
18:49:25  <Powerek38> Eddi|zuHause: thanks a lot :)
18:49:56  <Eddi|zuHause> there also used to be a truck set, but that was not finished afaik
18:50:59  <Powerek38> Eddi|zuHause: I don't mind, I prefer rail transport for cargo in OTTD :)
18:51:53  * Yorick gets integrating xfire into openttd
18:52:06  * orudge returns
18:53:27  <Powerek38> great, it works, thanks a lot :)
18:53:29  *** Powerek38 [] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
18:53:37  *** ecke [~ecke@] has joined #openttd
18:54:50  *** Dred_furst [] has quit [Read error: Connection reset by peer]
18:56:16  * Belugas wonders why Yorick is always trying that kind of stunts... nevertheless, have fun :)
18:57:03  <Belugas> now, that is a nice guy :)  Powerek38... he did say "thanks" :D
18:57:05  <Yorick> Belugas: it provides a nice sdk
18:57:41  <Belugas> and you think we will merge that patch in trunk?  I don't think so...
18:57:52  <Belugas> not from me, at leat
18:57:57  <Belugas> least
18:58:02  <Yorick> why not?
18:58:44  <Belugas> why so?
18:58:46  * peter1138 ponders joystick control of vehicles!
18:58:57  <Belugas> and what to answer to the next who does the same thing?
18:58:58  * Prof_Frink Ponder Stibbons.
18:59:02  <Sacro> peter1138: again?
18:59:13  <Belugas> where is it going to stop?
18:59:17  <Sacro> heh
18:59:28  <Sacro> arstechnica reckon OOXML is dead
18:59:29  <Yorick> "Why Use It: Drive Increased Friend Recommendations
18:59:31  <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. "
19:00:04  <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...
19:00:06  <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."
19:00:17  <Sacro> get it on steam
19:00:38  <Rubidium> blablabla... but there's no trail of the sdk on their website
19:00:52  <Yorick>
19:01:40  <Rubidium> it's not even slightly cross platform
19:02:15  <glx> it's windows only, will never be in openttd
19:02:51  <Rubidium> so... all Windows devs are against it
19:02:58  <Yorick> hm
19:03:05  <Belugas> dll...
19:03:06  <Belugas> lol
19:03:11  <Yorick> they added the support
19:03:12  <Belugas> poor Yorick...
19:03:37  <Belugas> we've already took a look at it in the past
19:03:40  <Prof_Frink> Alsa poor Yorick, I knew him Oss.
19:03:48  <Belugas> as far as i can see, nothing has changed
19:06:41  <peter1138> Oss?
19:06:49  <Yorick> Alsa?
19:07:03  <peter1138> Oh...
19:08:18  *** TinoM [] has quit [Quit: Verlassend]
19:08:28  *** lobster_MB [~michielbr@] has joined #openttd
19:09:39  <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.
19:10:18  <Fennec> haha
19:10:57  <Fennec> Yorick: Xfire OpenTTD support? :P
19:15:36  <Yorick> Fennec: Xfire supports openttd
19:18:06  <Belugas> XFire: openttd supports Yorick
19:18:56  <Sacro> openttd: yoricks Xfire
19:19:20  <Fennec> spiffy :)
19:19:35  <Prof_Frink> supports: Xfire Yorick
19:20:10  <Sacro> ooh
19:20:15  <Sacro> Euro Truck Simluator
19:20:17  <Sacro> *downloads*
19:24:01  *** Wezz6400 [] has joined #openttd
19:32:17  <glx> Sacro: it's not out yet
19:32:44  <Sacro> glx: is on usenet
19:33:05  <glx> <-- point 4
19:33:29  <Sacro> oh i know
19:33:30  <glx> it's out in germany though
19:33:43  <Sacro> i don't see the pirates calling it a "demo"
19:33:51  <Sacro> as a real pirate doesn't release demos
19:33:56  <Sacro> that's just stupid
19:36:02  <Sacro> grrr
19:36:20  <Sacro> the new version of grabit supports SSL but asks you if you want the port changing to 563 all the time
19:36:28  <Sacro> and no longer supports >10 connections
19:37:34  *** Wezz6400 [] has quit [Quit: Wezz6400]
19:41:31  *** fonso [] has joined #openttd
19:45:31  *** Purno [] has quit [Read error: Connection reset by peer]
19:46:04  <peter1138> SCS Software...
19:46:17  <peter1138> Their other stuff was shit :(
19:49:27  <ln> what else have they made?
19:52:56  <Sacro> fair few truck driving games
19:52:57  *** stillunk1own [] has quit [Read error: Connection reset by peer]
19:53:11  *** stillunknown [] has joined #openttd
19:54:28  <peter1138> And the bus one.
19:56:20  *** LilDood [] has joined #openttd
20:02:58  <ln> how do i add a restaurant car to a train
20:03:39  *** grumbel [] has joined #openttd
20:06:51  <peter1138> I don't think any set has one to add.
20:09:34  *** Farden123 [] has joined #openttd
20:15:38  <Fennec> restraunt car? :) what does that do, in terms of game play?
20:15:40  *** lobster_MB [~michielbr@] has quit [Quit: This computer has gone to sleep]
20:16:26  <Fennec> maybe a certain number of them could reduce passenger value falloff over time....
20:16:43  * Fennec shrugs.
20:16:55  *** Farden [] has quit [Ping timeout: 480 seconds]
20:17:28  <frosch123> they load food, which vanishes until the destination is reached.
20:17:46  <frosch123> though the weight of the train stays constant
20:21:05  *** Yorick [] has quit [Quit: Poef!]
20:21:09  <Fennec> loading food sounds like a logistical PITA.
20:21:32  <Prof_Frink> Fennec: Only loading flat breads.
20:23:38  <Eddi|zuHause> ln: some consists in the DBSetXL have dining cars
20:28:36  *** fonso [] has left #openttd [Kopete 0.12.7 :]
20:29:12  *** Farden123 [] has quit [Ping timeout: 480 seconds]
20:39:05  *** Wezz6400 [] has joined #openttd
20:39:15  <ln> are they economically useful?
20:39:19  *** Progman [] has joined #openttd
20:39:56  <Eddi|zuHause> not really... they are normal long distance passenger coaches, only they pack less passengers
20:51:13  <Eddi|zuHause> haha... "critical buffer overflow in µTorrent and BitTorrent. Solution for µTorrent: update. Solution for BitTorrent: switch to µTorrent."
20:52:55  <Wolf01> lol?
20:57:17  *** Farden123 [] has joined #openttd
20:57:37  *** frosch123 [] has quit [Remote host closed the connection]
20:59:59  <SpComb> can has url?
21:00:19  *** Ridayah_ [] has quit [Quit: The Rise and Fall of the Heavens themselves is dependant upon Humanity's belief and disbelief.]
21:01:52  <Eddi|zuHause> <- it's in german
21:02:35  * glx updates
21:03:19  <Eddi|zuHause> <- from the links in the article
21:03:40  *** lobster_MB [~michielbr@] has joined #openttd
21:12:13  *** Guest1543 [] has left #openttd []
21:12:40  *** KillaloT [] has quit [Quit:  Like's GUI?  Then try HydraIRC -> <-]
21:14:55  *** ben_goodger [] has joined #openttd
21:16:37  *** Wezz6400_ [] has joined #openttd
21:16:49  *** Zealotus [] has quit [Read error: Connection reset by peer]
21:17:18  *** Zealotus [] has joined #openttd
21:19:39  *** Farden [] has joined #openttd
21:23:29  *** Wezz6400 [] has quit [Ping timeout: 480 seconds]
21:23:53  *** Guest1543 [] has joined #openttd
21:24:25  *** Farden123 [] has quit [Ping timeout: 480 seconds]
21:36:44  *** Guest1543 [] has quit [Quit: Guest1543]
21:37:15  *** david [] has joined #openttd
21:37:40  *** david is now known as Guest1591
21:40:00  *** a1270 [] has joined #openttd
21:41:00  <peter1138> Fortunately 'VS.NET' is nothing like HydraIRC, because HydraIRC is shit.
21:43:42  <Prof_Frink> Surely your decision on which irc client to use should be made on the quality of that client.
21:43:59  <Prof_Frink> Not some other random piece of software.
21:44:22  <Prof_Frink> Like the taste of bananas? Try sausages!
21:44:31  <orudge> I choose to use mIRc because I like MS Paint!
21:44:31  <orudge> *mIRC
21:45:40  <Prof_Frink> orudge hates The Freedom.
21:47:43  <Eddi|zuHause> i chose to use Konversation because i like KDE... was that wrong?
21:48:40  <Prof_Frink> I use irssi because I like Konsole :)
21:49:29  *** Farden123 [] has joined #openttd
21:51:11  <Fennec> hydraIRC is the spammiest-use-me-/quit-msg IRC client evar
21:51:26  <glx> KVirc works well enough for me
21:52:20  <peter1138> BitchX used to be, but hardly anyone uses that these days.
21:52:38  * peter1138 > sleep
21:54:19  *** Farden [] has quit [Ping timeout: 480 seconds]
21:58:21  *** lobster_MB [~michielbr@] has quit [Quit: Leaving]
22:02:19  *** tokai|madspace [] has quit [Ping timeout: 480 seconds]
22:04:07  *** tokai|madspace [] has joined #openttd
22:04:11  *** jni [] has joined #openttd
22:19:11  *** DJNekkid [] has quit [Read error: Connection reset by peer]
22:20:34  *** divo [] has joined #openttd
22:23:22  *** fjb [] has quit [Quit: Leaving.]
22:25:43  *** dvo [] has joined #openttd
22:25:43  *** divo [] has quit [Read error: Connection reset by peer]
22:31:53  * prakti uses irssi and that stands.
22:32:29  * prakti is not one of those cruel guys who push around poor mouses all the time. ;-)
22:32:59  <Prof_Frink> prakti: The how do you point at the appropriate xterm?
22:41:34  *** rortom [] has joined #openttd
22:42:04  *** LilDood [] has quit [Ping timeout: 480 seconds]
22:44:08  <Wolf01> 'night
22:44:13  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
22:48:02  <Eddi|zuHause> with the eye view camera, obviously ;)
22:50:48  <ben_goodger> touché, kind sir
22:52:38  <Bjarni> I generally use a finger to point at objects
22:52:48  <Bjarni> either that or an object pointer
22:58:05  *** Brianetta [] has quit [Quit: TschÌß]
23:04:09  *** Farden123 [] has quit [Ping timeout: 480 seconds]
23:07:42  *** Yexo [] has quit [Ping timeout: 480 seconds]
23:08:51  *** Wezz6400_ [] has quit [Quit: brb]
23:27:44  *** Guest1591 [] has quit [Quit: Guest1591]
23:31:16  *** Dred_furst [] has joined #openttd
23:31:52  *** Dred_furst [] has quit []
23:36:48  *** fmauNeko is now known as fmauNekAway
23:36:52  *** Digitalfox [] has joined #openttd
23:42:19  *** fmauNekAway is now known as fmauNeko
23:48:32  *** welshdragon is now known as welshdra-gone

Powered by YARRSTE version: svn-trunk