Times are UTC Toggle Colours
00:01:12 <SquireJames> Anyone? 00:08:33 <Tekky> Is this what you are looking for? http://wiki.ttdpatch.net/tiki-index.php?page=Action0Trains#Long_format_introduction_date_2A_ 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 [andyf@dangermouse.pod4.org] has quit [Read error: Connection reset by peer] 00:20:28 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Quit: reboot] 00:22:20 *** lobster_MB [~michielbr@86.89.201.189] has quit [Quit: This computer has gone to sleep] 00:22:28 *** ob0t [andyf@dangermouse.pod4.org] has joined #openttd 00:29:02 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd 00:29:03 <fmauNeko> legal question: the openttd logo is totally free ? 00:29:22 *** Dred_furst [~Dred_furs@user-5440e40a.wfd80a.dsl.pol.co.uk] 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 [~johekr@p54B74F46.dip.t-dialin.net] has quit [Read error: Connection reset by peer] 00:33:12 *** Eddi|zuHause [~johekr@p54B76660.dip.t-dialin.net] 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 [~Wezz6400@ndb.demon.nl] 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"): http://wiki.ttdpatch.net/tiki-index.php?page=ThroughSignals:Alpha 00:59:22 *** grumbel [~grumbel@i577BAD3C.versanet.de] 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: http://wiki.openttd.org/index.php/Advanced_Main_Line_Depot 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 [~asd@0x3e42e6e6.adsl.cybercity.dk] has quit [Read error: Connection reset by peer] 01:09:16 *** divo [~asd@0x3e42e6e6.adsl.cybercity.dk] 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 [~asd@0x3e42e6e6.adsl.cybercity.dk] 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: http://www.tt-forums.net/viewforum.php?f=56 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_ [~sucks@dslb-084-058-143-198.pools.arcor-ip.net] has joined #openttd 01:57:18 *** Fuco [~dota.keys@ip-105.imafexbb.sk] 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 [~geetee@cs181040004.pp.htv.fi] has joined #openttd 02:02:41 *** Frostregen [~sucks@dslb-084-058-124-074.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds] 02:02:42 *** Frostregen_ is now known as Frostregen 02:04:22 *** stillunk1own [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Ping timeout: 480 seconds] 02:07:36 *** fmauNeko [~fmauNeko@thor.fmauneko.eu] 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 [~geetee@cs181040004.pp.htv.fi] has quit [Ping timeout: 480 seconds] 02:09:06 *** KritiK [~Maxim@93-80-42-225.broadband.corbina.ru] 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 [~fmauNeko@thor.fmauneko.eu] 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 [~david@c-24-62-103-46.hsd1.ma.comcast.net] 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_ [~elmex@e180069239.adsl.alicedsl.de] 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 [~elmex@e180068138.adsl.alicedsl.de] 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 [~me@219-90-231-33.ip.adam.com.au] 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 [~chatzilla@p5493BF76.dip.t-dialin.net] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]] 03:45:31 *** flowOver [~J@S01060016e65abad7.gv.shawcable.net] has joined #openttd 03:52:01 *** Crabman [~me@219-90-231-33.ip.adam.com.au] has quit [] 04:00:11 *** Gekz_ [~brendan@123-243-206-102.static.tpgi.com.au] has quit [Quit: leaving] 04:38:14 *** Rexxars [~rexxars@62.113.133.253] has quit [Quit: edgepro: A man who smiles when things go wrong knows who to blame.] 04:39:38 *** Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd 04:52:40 *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Quit: Leaving.] 04:54:48 *** Reemo [Dr_Jekyll@p57B0DD76.dip.t-dialin.net] has quit [Quit: http://www.lagerwiki.de - das Wiki rund um's Thema Lager und Logistik] 05:02:28 *** dlunch [~dlunch@61.108.29.49] has quit [Remote host closed the connection] 05:02:56 *** dlunch [~dlunch@61.108.29.49] 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 [Suisse@bas15-montrealak-1177943779.dsl.bell.ca] has joined #openttd 05:41:18 *** Suisse [Suisse@bas15-montrealak-1177943779.dsl.bell.ca] has quit [Ping timeout: 480 seconds] 05:56:25 *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has joined #openttd 05:56:55 *** Zorni [zorn@e177230161.adsl.alicedsl.de] has joined #openttd 06:01:25 <Frostregen> http://saddam.ath.cx/ttdmap.jpg ;) 06:04:17 *** Zorn [zorn@e177235213.adsl.alicedsl.de] 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_ [~ridayah@12-208-15-67.client.mchsi.com] has joined #openttd 06:08:49 *** Ridayah [~ridayah@12-208-15-67.client.mchsi.com] 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@61.108.29.49] has quit [Remote host closed the connection] 06:20:35 *** mikl [~mikl@0304ds2-ba.0.fullrate.dk] 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 [~J@S01060016e65abad7.gv.shawcable.net] has joined #openttd 06:51:19 *** ob0t_ [andyf@dangermouse.pod4.org] has joined #openttd 06:51:50 *** Frostregen [~sucks@dslb-084-058-143-198.pools.arcor-ip.net] has quit [Quit: und weg] 06:52:19 *** ob0t [andyf@dangermouse.pod4.org] has quit [Read error: Connection reset by peer] 06:52:19 *** Eddi|zuHause [~johekr@p54B76660.dip.t-dialin.net] has quit [Remote host closed the connection] 06:52:40 *** Eddi|zuHause [~johekr@p54B76660.dip.t-dialin.net] has joined #openttd 06:54:06 *** flowOver [~J@S01060016e65abad7.gv.shawcable.net] has quit [Ping timeout: 480 seconds] 07:04:04 *** mikl [~mikl@0304ds2-ba.0.fullrate.dk] has quit [Quit: Leaving...] 07:07:12 *** Rexxars [~rexxars@62.113.133.253] 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 [~J@S01060016e65abad7.gv.shawcable.net] has joined #openttd 07:24:53 *** SquireJames [SquireJame@72.24.41.5] 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 [~J@S01060016e65abad7.gv.shawcable.net] has quit [Ping timeout: 480 seconds] 07:33:05 *** thingwath [~thingwath@heimdall.palisada.net] 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 [~brian@client-86-27-108-163.brnt.adsl.virgin.net] 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 [~Tino@i59F57E99.versanet.de] has joined #openttd 07:47:35 *** TinoM [~Tino@i59F57E99.versanet.de] 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 [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [Quit: TschÃŒÃ] 08:09:39 <De_Ghost> what wood did u use/. 08:12:10 *** Prof_Frink [~proffrink@5adb1d9d.bb.sky.com] 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 [~peter@svn.bucks.net] has quit [Ping timeout: 480 seconds] 08:36:59 *** peter1138 [~peter@svn.bucks.net] has joined #openttd 08:37:00 *** mode/#openttd [+o peter1138] by ChanServ 08:37:36 *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has joined #openttd 08:51:58 *** CelestarT42p [~Jadzia_Da@pD9E4EF1F.dip.t-dialin.net] has joined #openttd 08:52:00 <CelestarT42p> heyo 08:52:08 *** tokai|madspace [~tokai@p54B80294.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 08:52:28 <Ailure> hmm 08:52:29 <Ailure> haha 08:52:32 *** fonso [~fonso@brln-d9bac583.pool.mediaWays.net] has joined #openttd 08:52:37 <Ailure> neat newGRF presets 08:52:53 <CelestarT42p> peter1138: got a minute? 08:54:35 *** tokai|madspace [~tokai@p54B813AA.dip0.t-ipconnect.de] has joined #openttd 09:00:59 *** mucht_work [~Martin@143.50.125.24] has joined #openttd 09:01:52 *** mucht_work [~Martin@143.50.125.24] has quit [Remote host closed the connection] 09:06:53 *** mucht_work [~Martin@143.50.125.24] has joined #openttd 09:17:41 *** Eddi|zuHause [~johekr@p54B76660.dip.t-dialin.net] has quit [Remote host closed the connection] 09:18:01 *** Eddi|zuHause [~johekr@p54B76660.dip.t-dialin.net] has joined #openttd 09:22:42 *** Wolf01 [~wolf01@host129-15-dynamic.5-87-r.retail.telecomitalia.it] has joined #openttd 09:22:56 <Wolf01> hello 09:25:44 *** Farden [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] has joined #openttd 09:37:48 *** Bjarni [~Bjarni@0x50a46ad5.virnxx14.dynamic.dsl.tele.dk] has joined #openttd 09:37:49 *** mode/#openttd [+o Bjarni] by ChanServ 09:38:05 *** Yorick [~Yorick@s55924da0.adsl.wanadoo.nl] 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 [~asd@0x3e42e6e6.adsl.cybercity.dk] 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> senduit.com :) 09:51:38 <Kloopy> Indeed 09:51:59 <peter1138> Oh, right... 09:52:06 *** divo [~asd@0x3e42e6e6.adsl.cybercity.dk] 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 [~asd@0x3e42e6e6.adsl.cybercity.dk] 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: http://senduit.com/71cd51 09:53:17 <CelestarT42p> peter1138: cool 09:53:26 <peter1138> http://84.246.152.229:8000/ 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: http://bugs.openttd.org/task/2037 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 [~asd@0x3e42e6e6.adsl.cybercity.dk] has joined #openttd 09:58:42 *** divo [~asd@0x3e42e6e6.adsl.cybercity.dk] 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 http://arwen.fvfischer.de:8000 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 212.67.121.123 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 [~proffrink@5ad915a5.bb.sky.com] 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 [~brian@client-86-27-108-163.brnt.adsl.virgin.net] 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 http://hg.openttd.org/trunk 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 [~johekr@p54B76660.dip.t-dialin.net] has quit [Remote host closed the connection] 10:21:21 <peter1138> Nope, just 3 files to manually merge. 10:21:31 *** Eddi|zuHause [~johekr@p54B76660.dip.t-dialin.net] 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 [~Dred_furs@user-5440e40a.wfd80a.dsl.pol.co.uk] 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 [~stillunkn@82-136-225-75.ip.telfort.nl] 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 [~Roujin@p54971A69.dip0.t-ipconnect.de] 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 http://wiki.openttd.org/index.php/OpenTTDDevBlackBook/Network/Desync_debugging 10:47:38 *** Progman [~progman@p57A1D4B9.dip.t-dialin.net] 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 [~johekr@p54B76660.dip.t-dialin.net] has quit [Remote host closed the connection] 10:51:08 *** Eddi|zuHause [~johekr@p54B76660.dip.t-dialin.net] has joined #openttd 10:51:37 <CelestarT42p> or cerr rather :P 10:53:54 <CelestarT42p> peter1138: http://wiki.openttd.org/index.php/Cargo_Packets 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 [~chatzilla@p5493F848.dip.t-dialin.net] 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@86.89.201.189] 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@86.89.201.189] 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 [Doorslamme@PIPP-p-203-54-229-175.prem.tmns.net.au] 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@86.89.201.189] 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@86.89.201.189] has quit [Ping timeout: 480 seconds] 11:25:59 <CelestarT42p> peter1138: cannot reproduce? 11:26:39 *** ecke [~ecke@213.195.202.130] 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 [~Jadzia_Da@pD9E4EF1F.dip.t-dialin.net] 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 [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] 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 [~Bjarni@0x50a46ad5.virnxx14.dynamic.dsl.tele.dk] 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@86.89.201.189] 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: http://www.openttd.org/ 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 [glx@bny93-6-82-245-156-124.fbx.proxad.net] 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 [~kjetil@savner.vdsl2.no] 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@86.89.201.189] 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> http://www.tt-forums.net/viewtopic.php?p=718117#p718117 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 [~Cheese@24-117-51-112.cpe.cableone.net] 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 [~J@S01060016e65abad7.gv.shawcable.net] has quit [Quit: Leaving] 12:36:48 *** orudge [~orudge@80.247.163.103] has left #openttd [] 12:36:50 *** orudge [~orudge@80.247.163.103] 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 [~proffrink@5ad915a5.bb.sky.com] 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@86.89.201.189] 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 [~Maxim@78-106-178-166.broadband.corbina.ru] has joined #openttd 12:48:08 *** Prof_Frink [~proffrink@5ad545c8.bb.sky.com] 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 2.6.25.11-0.1-default 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> http://faux.uwcs.co.uk/presignals3.png <-- 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@86.89.201.189] 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 [~Brainstor@82-171-5-111.ip.telfort.nl] has quit [] 12:57:09 <Yorick> :) 12:57:17 *** Brainstorm [~Brainstor@82-171-5-111.ip.telfort.nl] 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_ [~chatzilla@static128-249.adsl.no] 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 [~fjb@p5485CA72.dip.t-dialin.net] 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 [~fjb@p5485CA72.dip.t-dialin.net] has left #openttd [] 13:01:47 <Yorick> servers are allowed to have empty names? 13:02:28 *** fjb [~fjb@p5485CA72.dip.t-dialin.net] has joined #openttd 13:05:08 <Eddi|zuHause> <FauxFaux> http://faux.uwcs.co.uk/presignals3.png <-- 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> (http://wiki.openttd.org/index.php/Railway_Stations#Double_entrance) 13:06:13 *** devilsadvocate [~user@203.200.95.130] 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> http://bugs.openttd.org/task/142 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 [~killalot@0x5738c8f9.rdnqu1.dynamic.dsl.tele.dk] 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@216.191.111.226] has left #openttd [] 13:31:42 *** Belugas [~belugas@216.191.111.226] 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> http://bugs.openttd.org/task/1644?project=1&pagenum=2 <- 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> http://www.ndesign-studio.com/demo/css-dock-menu/css-dock.html <- 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@145.94.202.133] 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 [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] 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> http://www.pikkarail.com/ttdp/ukrs/index.htm 14:13:23 <Brianetta> King of newgrf sets 14:13:36 <Brianetta> Everything Pikka touches is fabulous 14:13:49 *** Yorick [~Yorick@s55924da0.adsl.wanadoo.nl] 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 [~asd@0x3e42e6e6.adsl.cybercity.dk] has quit [Read error: Connection reset by peer] 14:16:07 *** divo [~asd@0x3e42e6e6.adsl.cybercity.dk] 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@61.108.29.49] has joined #openttd 14:20:32 *** dvo [~asd@0x3e42e6e6.adsl.cybercity.dk] has joined #openttd 14:20:32 *** divo [~asd@0x3e42e6e6.adsl.cybercity.dk] 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: http://wiki.openttd.org/index.php/Realistic_Path_Based_Signalling 14:30:55 *** dlunch_ [~dlunch@61.108.29.49] 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@86.89.201.189] 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 [~mchl@abed24.neoplus.adsl.tpnet.pl] 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@61.108.29.49] 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@86.89.201.189] 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 [~fjb@p5485CA72.dip.t-dialin.net] 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@61.108.29.49] 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 [~fjb@p5485CA72.dip.t-dialin.net] 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 [~asd@0x3e42e6e6.adsl.cybercity.dk] has quit [Read error: Connection reset by peer] 14:58:31 *** divo [~asd@0x3e42e6e6.adsl.cybercity.dk] 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 [Doorslamme@PIPP-p-203-54-229-175.prem.tmns.net.au] 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 [~Purno@5350931D.cable.casema.nl] has joined #openttd 15:08:36 <peter1138> That's a stupidly long reservation. 15:08:39 *** fonso [~fonso@brln-d9bac583.pool.mediaWays.net] has left #openttd [Kopete 0.12.7 : http://kopete.kde.org] 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 [~asd@0x3e42e6e6.adsl.cybercity.dk] 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 [~david@c-24-62-103-46.hsd1.ma.comcast.net] 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: http://img355.imageshack.us/my.php?image=segments2cw5.png 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 [~frosch@frnk-590fd04d.pool.einsundeins.de] has joined #openttd 15:26:45 <Brianetta> Wow. 15:26:52 *** Reemo [Dr_Jekyll@p57B0CCCB.dip.t-dialin.net] 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@86.89.201.189] 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 [~brendan@123-243-206-102.static.tpgi.com.au] has joined #openttd 15:50:42 *** Gekz [~brendan@123-243-206-102.static.tpgi.com.au] 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 [~brendan@123-243-206-102.static.tpgi.com.au] 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 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] 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 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] 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 [~fjb@p5485CA72.dip.t-dialin.net] has quit [Quit: Leaving.] 16:00:51 *** ProfFrink [~proffrink@5ad46219.bb.sky.com] 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 [~proffrink@5ad545c8.bb.sky.com] 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 [~brendan@123-243-206-102.static.tpgi.com.au] 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@203.200.95.130] 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 [~trainboy2@cp734887-a.gelen1.lb.home.nl] has joined #openttd 16:17:05 *** trainboy2004 [~trainboy2@cp734887-a.gelen1.lb.home.nl] has quit [] 16:17:15 *** TinoM [~Tino@i59F57E99.versanet.de] 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: http://wiki.openttd.org/index.php/Realistic_Path_Based_Signalling 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 [~Bjarni@0x50a46ad5.virnxx14.dynamic.dsl.tele.dk] 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 [~trainboy2@cp734887-a.gelen1.lb.home.nl] has joined #openttd 16:43:12 *** trainboy2004 [~trainboy2@cp734887-a.gelen1.lb.home.nl] 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 [~fjb@p5485CA72.dip.t-dialin.net] 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@86.89.201.189] 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 [~sucks@dslb-084-058-143-198.pools.arcor-ip.net] has joined #openttd 17:07:45 <Brianetta> Going home. 17:07:46 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] 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 [~fjb@p5485CA72.dip.t-dialin.net] 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@86.89.201.189] 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 [~fjb@p5485CA72.dip.t-dialin.net] has joined #openttd 17:24:43 *** Yorick [~Yorick@82-171-205-190.ip.telfort.nl] 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 [~fjb@p5485CA72.dip.t-dialin.net] has quit [Quit: Leaving.] 17:26:10 *** fjb [~fjb@p5485CA72.dip.t-dialin.net] 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@86.89.201.189] 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 [~dota.keys@ip-105.imafexbb.sk] 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 [~brian@client-86-27-108-163.brnt.adsl.virgin.net] 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@86.89.201.189] has joined #openttd 17:49:28 <DJNekkid> could anyone see the last post on this thread? http://www.tt-forums.net/viewtopic.php?f=26&t=38586&p=718301#p718301 17:49:47 <orudge> as in your post? 17:50:30 *** Roujin [~Roujin@p54971A69.dip0.t-ipconnect.de] 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 [~mchl@abed24.neoplus.adsl.tpnet.pl] 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@213.195.202.130] 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 [~progman@p57A1D4B9.dip.t-dialin.net] has quit [Remote host closed the connection] 18:10:52 *** ecke [~ecke@213.195.202.130] 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 [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd 18:19:21 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Read error: Connection reset by peer] 18:20:47 *** ecke [~ecke@213.195.202.130] has quit [Quit: ecke] 18:22:59 *** Lenny [~Lenny@d83-181-157-80.cust.tele2.nl] has joined #openttd 18:23:30 *** Lenny is now known as Guest1571 18:29:52 *** Guest1571 [~Lenny@d83-181-157-80.cust.tele2.nl] has quit [Quit: Bye for now!] 18:36:05 *** lobster_MB [~michielbr@86.89.201.189] has quit [Quit: This computer has gone to sleep] 18:45:20 *** mikl [~mikl@0304ds2-ba.0.fullrate.dk] 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 [~chatzilla@ijm42.internetdsl.tpnet.pl] 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 [~chatzilla@ijm42.internetdsl.tpnet.pl] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]] 18:53:37 *** ecke [~ecke@213.195.202.130] has joined #openttd 18:54:50 *** Dred_furst [~Dred_furs@user-5440e40a.wfd80a.dsl.pol.co.uk] 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> http://www.xfire.com/cms/xf_game_sdk/ 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 [~Tino@i59F57E99.versanet.de] has quit [Quit: Verlassend] 19:08:28 *** lobster_MB [~michielbr@86.89.201.189] 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 [~Wezz6400@ndb.demon.nl] 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> http://www.eurotrucksimulator.com/faq.php <-- 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 [~Wezz6400@ndb.demon.nl] has quit [Quit: Wezz6400] 19:41:31 *** fonso [~fonso@brln-d9bac583.pool.mediaWays.net] has joined #openttd 19:45:31 *** Purno [~Purno@5350931D.cable.casema.nl] 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 [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Read error: Connection reset by peer] 19:53:11 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd 19:54:28 <peter1138> And the bus one. 19:56:20 *** LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has joined #openttd 20:02:58 <ln> how do i add a restaurant car to a train 20:03:39 *** grumbel [~grumbel@i577BB526.versanet.de] has joined #openttd 20:06:51 <peter1138> I don't think any set has one to add. 20:09:34 *** Farden123 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] has joined #openttd 20:15:38 <Fennec> restraunt car? :) what does that do, in terms of game play? 20:15:40 *** lobster_MB [~michielbr@86.89.201.189] 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 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] 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 [~Yorick@82-171-205-190.ip.telfort.nl] 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 [~fonso@brln-d9bac583.pool.mediaWays.net] has left #openttd [Kopete 0.12.7 : http://kopete.kde.org] 20:29:12 *** Farden123 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] has quit [Ping timeout: 480 seconds] 20:39:05 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd 20:39:15 <ln> are they economically useful? 20:39:19 *** Progman [~progman@p57A1D4B9.dip.t-dialin.net] 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 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] has joined #openttd 20:57:37 *** frosch123 [~frosch@frnk-590fd04d.pool.einsundeins.de] has quit [Remote host closed the connection] 20:59:59 <SpComb> can has url? 21:00:19 *** Ridayah_ [~ridayah@12-208-15-67.client.mchsi.com] has quit [Quit: The Rise and Fall of the Heavens themselves is dependant upon Humanity's belief and disbelief.] 21:01:52 <Eddi|zuHause> http://www.heise.de/newsticker/Kritische-Luecke-in-ueTorrent-und-BitTorrent--/meldung/114216 <- it's in german 21:02:35 * glx updates 21:03:19 <Eddi|zuHause> http://seclists.org/dailydave/2008/q3/0155.html <- from the links in the article 21:03:40 *** lobster_MB [~michielbr@86.89.201.189] has joined #openttd 21:12:13 *** Guest1543 [~david@c-24-62-103-46.hsd1.ma.comcast.net] has left #openttd [] 21:12:40 *** KillaloT [~killalot@0x5738c8f9.rdnqu1.dynamic.dsl.tele.dk] has quit [Quit: Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-] 21:14:55 *** ben_goodger [~ben@host81-153-29-228.range81-153.btcentralplus.com] has joined #openttd 21:16:37 *** Wezz6400_ [~Wezz6400@ndb.demon.nl] has joined #openttd 21:16:49 *** Zealotus [~Ping@78-69-54-150-no70.tbcn.telia.com] has quit [Read error: Connection reset by peer] 21:17:18 *** Zealotus [~Ping@78-69-54-150-no70.tbcn.telia.com] has joined #openttd 21:19:39 *** Farden [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] has joined #openttd 21:23:29 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Ping timeout: 480 seconds] 21:23:53 *** Guest1543 [~david@c-24-62-103-46.hsd1.ma.comcast.net] has joined #openttd 21:24:25 *** Farden123 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] has quit [Ping timeout: 480 seconds] 21:36:44 *** Guest1543 [~david@c-24-62-103-46.hsd1.ma.comcast.net] has quit [Quit: Guest1543] 21:37:15 *** david [~david@c-24-62-103-46.hsd1.ma.comcast.net] has joined #openttd 21:37:40 *** david is now known as Guest1591 21:40:00 *** a1270 [~Cheese@24-117-51-112.cpe.cableone.net] 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 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] 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 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] has quit [Ping timeout: 480 seconds] 21:58:21 *** lobster_MB [~michielbr@86.89.201.189] has quit [Quit: Leaving] 22:02:19 *** tokai|madspace [~tokai@p54B813AA.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 22:04:07 *** tokai|madspace [~tokai@p54B826AF.dip0.t-ipconnect.de] has joined #openttd 22:04:11 *** jni [~geetee@cs181040004.pp.htv.fi] has joined #openttd 22:19:11 *** DJNekkid [~chatzilla@static128-249.adsl.no] has quit [Read error: Connection reset by peer] 22:20:34 *** divo [~asd@0x3e42e6e6.adsl.cybercity.dk] has joined #openttd 22:23:22 *** fjb [~fjb@p5485CA72.dip.t-dialin.net] has quit [Quit: Leaving.] 22:25:43 *** dvo [~asd@0x3e42e6e6.adsl.cybercity.dk] has joined #openttd 22:25:43 *** divo [~asd@0x3e42e6e6.adsl.cybercity.dk] 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 [~rortom@p57B7DE6E.dip.t-dialin.net] has joined #openttd 22:42:04 *** LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has quit [Ping timeout: 480 seconds] 22:44:08 <Wolf01> 'night 22:44:13 *** Wolf01 [~wolf01@host129-15-dynamic.5-87-r.retail.telecomitalia.it] 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 [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [Quit: TschÃŒÃ] 23:04:09 *** Farden123 [~jk3farden@lns-bzn-48f-81-56-247-196.adsl.proxad.net] has quit [Ping timeout: 480 seconds] 23:07:42 *** Yexo [~Yexo@32-88-ftth.onsneteindhoven.nl] has quit [Ping timeout: 480 seconds] 23:08:51 *** Wezz6400_ [~Wezz6400@ndb.demon.nl] has quit [Quit: brb] 23:27:44 *** Guest1591 [~david@c-24-62-103-46.hsd1.ma.comcast.net] has quit [Quit: Guest1591] 23:31:16 *** Dred_furst [~Dred_furs@user-5440e40a.wfd80a.dsl.pol.co.uk] has joined #openttd 23:31:52 *** Dred_furst [~Dred_furs@user-5440e40a.wfd80a.dsl.pol.co.uk] has quit [] 23:36:48 *** fmauNeko is now known as fmauNekAway 23:36:52 *** Digitalfox [~Digitalfo@bl10-223-153.dsl.telepac.pt] has joined #openttd 23:42:19 *** fmauNekAway is now known as fmauNeko 23:48:32 *** welshdragon is now known as welshdra-gone