Times are UTC Toggle Colours
00:04:13 *** rortom [~rortom@p57B7BE2A.dip.t-dialin.net] has quit [] 00:10:25 *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Quit: Leaving.] 00:11:51 *** Chrill [~chrischri@c80-216-64-31.bredband.comhem.se] has joined #openttd 00:16:33 *** Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has quit [Quit: Leaving] 00:33:14 *** Eddi|zuHause2 [~johekr@p54B76989.dip.t-dialin.net] has joined #openttd 00:40:07 *** Eddi|zuHause3 [~johekr@p54B75E39.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 00:48:37 *** Chrill is now known as Nut-Losh 00:50:41 *** KritiK [~Maxim@93-80-36-72.broadband.corbina.ru] has quit [Quit: Leaving] 01:01:08 *** Nut-Losh is now known as Chrill 01:01:18 *** Chrill [~chrischri@c80-216-64-31.bredband.comhem.se] has quit [Quit: dead'd] 01:05:28 *** a1271 [~Cheese@24-117-51-112.cpe.cableone.net] has quit [Quit: a1271] 01:07:33 *** Forked [kjs@termstua.com] has quit [Ping timeout: 480 seconds] 01:08:15 *** KillaloT [~killalot@0x5738ccc3.rdnqu1.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer] 01:11:32 *** a1270 [~Cheese@24-117-51-112.cpe.cableone.net] has joined #openttd 01:13:36 *** Forked [kjs@termstua.com] has joined #openttd 01:21:57 *** Noetloj [~105Adam@5acb31ac.bb.sky.com] has quit [] 01:35:55 *** fmauNeko is now known as fmauNekAway 01:42:02 *** NukeBuster [~NukeBuste@80.101.115.82] has quit [Quit: http://www.interplay.com/] 01:46:08 *** Forked [kjs@termstua.com] has quit [Ping timeout: 480 seconds] 01:46:44 *** Chrill [~chrischri@c80-216-64-31.bredband.comhem.se] has joined #openttd 01:48:15 *** Forked [kjs@termstua.com] has joined #openttd 01:59:32 *** Chrill [~chrischri@c80-216-64-31.bredband.comhem.se] has quit [] 02:03:37 *** TinoM [~Tino@i59F54912.versanet.de] has quit [Ping timeout: 480 seconds] 02:10:58 *** TinoM [~Tino@i59F54912.versanet.de] has joined #openttd 02:21:27 *** Forked [kjs@termstua.com] has quit [Ping timeout: 480 seconds] 02:23:40 *** Forked [kjs@termstua.com] has joined #openttd 02:29:26 *** nicfer [~Administr@168.226.105.56] has joined #openttd 02:30:03 <nicfer> I have one idea for the webpage 02:30:24 <nicfer> what about something like Wormux one? 02:30:32 *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Quit: bye] 02:30:51 <nicfer> that means, using the wiki engine 02:36:14 <CIA-5> OpenTTD: belugas * r13887 /trunk/src/ (5 files): 02:36:14 <CIA-5> OpenTTD: -Codechange: Replace numbers with Colours enum on autoreplace, build_vehicle, cheat, depot and dock guis. 02:36:14 <CIA-5> OpenTTD: The fact that it goes alphabetically is pure coincidence. 02:41:24 *** Zahl [~Zahl@g229214104.adsl.alicedsl.de] has quit [Quit: (~_~]"] 02:59:12 *** Forked [kjs@termstua.com] has quit [Ping timeout: 480 seconds] 02:59:34 <CIA-5> OpenTTD: belugas * r13888 /trunk/src/misc_gui.cpp: -Codechange: Replace numbers with Colours enum on miscellaneous guis. 03:00:51 *** TinoM| [~Tino@i59F55DED.versanet.de] has joined #openttd 03:02:20 *** elmex_ [~elmex@e180066143.adsl.alicedsl.de] has joined #openttd 03:06:52 *** elmex [~elmex@e180067141.adsl.alicedsl.de] has quit [Ping timeout: 480 seconds] 03:07:18 *** elmex_ is now known as elmex 03:07:36 *** TinoM [~Tino@i59F54912.versanet.de] has quit [Ping timeout: 480 seconds] 03:11:02 *** nicfer [~Administr@168.226.105.56] has left #openttd [] 03:13:35 *** Forked [kjs@termstua.com] has joined #openttd 03:13:52 <CIA-5> OpenTTD: belugas * r13889 /trunk/src/transparency_gui.cpp: 03:13:52 <CIA-5> OpenTTD: -Codechange: Replace numbers with Colours enum on transparency gui. 03:13:52 <CIA-5> OpenTTD: -Fix: "true" is not a color. COLOUR_PALE_GREEN should look better, at least in the code ;) 03:18:23 <Belugas> time to hit the bed, otherwise, i'll never finish... 03:21:27 *** Eddi|zuHause3 [~johekr@p54B771CF.dip.t-dialin.net] has joined #openttd 03:25:16 *** Eddi|zuHause2 [~johekr@p54B76989.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 03:55:35 *** Smoovious [~imptruck@63.99.218.194] has quit [Quit: "The things we fear the most... have already happened to us." --Deepak Chopra] 04:25:24 <Celestar> morning 05:01:18 <Celestar> peter1138: how's progress? 05:12:39 *** ecke [~ecke@213.195.202.130] has quit [Read error: Connection reset by peer] 05:13:07 *** ecke [~ecke@213.195.202.130] has joined #openttd 05:30:17 *** Gekz_ [~brendan@123-243-206-102.static.tpgi.com.au] has joined #openttd 05:31:51 *** ecke [~ecke@213.195.202.130] has quit [Read error: Connection reset by peer] 05:31:54 *** Gekz [~brendan@123-243-206-102.static.tpgi.com.au] has quit [Ping timeout: 480 seconds] 05:37:01 <peter1138> Hmm, well... 05:43:22 <peter1138> I made some progress. Cargo without destinations is now handled better. 05:47:21 *** Rexxars [~rexxars@85.19.218.24] has quit [Ping timeout: 480 seconds] 05:47:29 *** TinoM| [~Tino@i59F55DED.versanet.de] has quit [Quit: Verlassend] 05:47:42 <CIA-5> OpenTTD: peter1138 * r13890 /trunk/src/transparency_gui.cpp: 05:47:42 <CIA-5> OpenTTD: -Codechange: Simplify drawing of invisibilty buttons in the transparency gui -- 05:47:42 <CIA-5> OpenTTD: the real widgets above already have coordinates so there is no need to hardcode 05:47:42 <CIA-5> OpenTTD: them again. As an added bonus the invisibility buttons now line up properly. 05:50:06 *** TinoM [~Tino@i59F55DED.versanet.de] has joined #openttd 05:52:11 <peter1138> SmatZ, whatever happened to using real widgets where possible? 06:00:20 *** bleepy [bleepy@5ad34870.bb.sky.com] has joined #openttd 06:00:21 <ccfreak2k> The OpenGL blitter thread seems to have stopped dead. 06:16:29 *** ecke [~ecke@213.195.202.130] has joined #openttd 06:42:29 *** Ridayah [~ridayah@12-208-15-67.client.mchsi.com] has quit [Ping timeout: 480 seconds] 06:49:56 <peter1138> Celestar, ping? 06:59:14 <Celestar> peter1138: pong 06:59:50 <Celestar> peter1138: let me read through your changes first :D 07:00:43 <peter1138> I'm getting stuff not unloading sometimes :/ 07:01:18 <Celestar> peter1138: me too 07:01:19 <Celestar> apparently 07:01:49 <peter1138> Of course, now I'm looking for it it doesn't happen :o 07:02:35 <Celestar> other than that, do we get any more asserts and crap? 07:03:08 <peter1138> I've not had one for a while. 07:04:04 <peter1138> Hmm, non-gradual loading is totally busted. 07:05:50 <peter1138> Works if there's only one packet. 07:07:20 <Celestar> peter1138: I'm pretty sorry, but I have little time today to work on it :( 07:07:25 <Celestar> peter1138: maybe this afternoon 07:07:34 <Celestar> but I'll keep a watch on changes :D 07:08:02 <Celestar> peter1138: but I'll be online anyway, so just keep talking (= 07:08:43 *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has joined #openttd 07:11:57 *** fonso [~fonso@brln-d9bacf2b.pool.mediaWays.net] has joined #openttd 07:14:13 <Celestar> peter1138: is it me or is the amount of passengers generated nothing short of insane? :P 07:14:26 <peter1138> It seems quite high, but we've not modified that, have we? 07:16:56 <Celestar> not that I know of 07:17:04 <Celestar> are we sure they're not multiplying? :P 07:18:55 * peter1138 tidying stuff up. 07:19:09 <peter1138> I *think* that these are the same, except for performance and additional looping: 07:19:20 <peter1138> packets.remove(cp); it = packets.begin(); 07:19:27 <peter1138> it = packets.erase(it); 07:19:51 * peter1138 tests 07:20:39 <Celestar> peter1138: when you remove and item from a container, the the iterator that points to the delete object becomes invalid 07:20:46 <peter1138> yes 07:20:46 <Celestar> s/and/an 07:20:52 <peter1138> hence the "it = " 07:21:09 <peter1138> erase is also more efficient than remove 07:21:16 <peter1138> remove looks for the value in the list 07:21:23 <peter1138> erase already knows which entry to remove 07:21:29 <peter1138> and then returns the next entry 07:21:39 <Celestar> but whe start from "begin", don't we? 07:21:43 <Celestar> (in the first iteration I mean) 07:21:48 <Celestar> er first version 07:21:57 <peter1138> yeah 07:22:05 *** Doorslammer [Doorslamme@PIPP-p-203-54-229-69.prem.tmns.net.au] has joined #openttd 07:22:30 <peter1138> Basically 07:22:52 *** GoneWacko [~foo@adsl-58.35.Static.ssp.fi] has joined #openttd 07:23:37 <peter1138> See my last commit. 07:23:50 <Celestar> peter1138: aren't we usually removing the FIRST container of the list with that statement? 07:24:07 <Celestar> er no 07:25:14 <peter1138> hmm, committed a debug message again ;) 07:25:14 <Celestar> I concur with your changes (= 07:25:34 <Celestar> peter1138: he. 07:25:52 <peter1138> 10 lines gone, 2 lines added :D 07:26:18 <Celestar> I have a "svn diff | grep fprintf && echo 'debug messages remaining'" script :P 07:26:27 <peter1138> hehe 07:28:09 <Celestar> peter1138: about my helper functions in routing.cpp .. shouldn't we move them into the order class at some point? 07:28:21 <peter1138> Mmm, possibly should do. 07:28:45 <Celestar> k .. will do 07:32:57 <peter1138> Gah, my PC's too fast 07:35:56 <Ammler> good morning, nice topic :-) 07:39:49 <Ammler> as you are working that hard on the cargo destinations, a small question for non-dest code about transfer: would it be possible to "mark" cargo, so not the vehicels with same orders do load it again? 07:40:13 <Ammler> (i.e. airport<->city transfer) 07:40:47 <peter1138> who cares, it works properly with destinations... ;) 07:41:17 <peter1138> Or would do if these bugs were not there :o 07:44:20 <Ammler> heh 07:45:13 <fonso> new version of diagonal levelling and clearing without '°' and (uint)-1: http://www.tt-forums.net/download/file.php?id=95264 07:45:43 <Celestar> fonso: nice :d 07:45:44 <Celestar> :D 07:45:51 <Celestar> I hope I manage to test it this afternoon ;) 07:48:50 <Ammler> Celestar: peter1138: if you think the code is ready for MP testing, we would like to do it, that was one of the failing point of all old pax dest patches... 07:49:29 <Celestar> Ammler: will take a few more changes. the unloading/loading not not yet work corretly 07:49:32 <Celestar> correctly* 07:52:31 <peter1138> It is MP safe though ;) 07:53:28 <peter1138> It's odd. The vehicle will not unload properly for a few trips, and then suddenly it does. :o 07:55:02 *** fonso [~fonso@brln-d9bacf2b.pool.mediaWays.net] has left #openttd [Kopete 0.12.7 : http://kopete.kde.org] 07:56:58 <Celestar> meh. changing order_base.h sucks too 07:59:12 <peter1138> Got it. 07:59:26 <Celestar> you did? :D 08:00:38 <Celestar> peter1138: can we fix that warning in economy.cpp:1440. We should put parenthesis around (a & b) 08:04:54 <Celestar> HEM 08:05:08 <Celestar> after moving the helps into the order class, I'm getting undeffed references :S 08:05:09 <peter1138> Hmm? 08:08:55 <Celestar> meh 08:10:34 <Celestar> peter1138: does it work now? :D 08:11:07 <Celestar> peter1138: http://www.fvfischer.de/helpercleanup.diff <= can you have a look at this? 08:11:17 <peter1138> Seems to, however I'm sure it is not all correct yet. 08:11:54 *** fmauNekAway is now known as fmauNeko 08:12:42 <peter1138> Indeed, I'm right, it's not :D 08:18:28 <Celestar> peter1138: heh. the payment is WAAAAYYY off sometimes 08:18:39 <peter1138> :o 08:18:44 <peter1138> I'm rewriting MoveTo :o 08:18:46 <Celestar> or the display of it (= 08:19:52 <peter1138> Should all work now, heh 08:19:57 * peter1138 tests first though 08:22:38 * peter1138 sees 08:25:37 *** fmauNeko is now known as fmauNekAway 08:25:51 * peter1138 tests again 08:40:19 <peter1138> Ah... 08:42:38 <peter1138> Maybe this time ;) 08:42:45 <peter1138> it = packets.erase(it); 08:42:47 <peter1138> then ++it 08:42:52 <peter1138> in the for 08:42:55 <peter1138> is not good :) 08:43:44 <peter1138> GOT THE BASTARD 08:45:21 <Forked> victory! 08:46:05 <peter1138> Celestar: committed. 08:47:00 <peter1138> \o/ 08:47:43 <Celestar> wee :D 08:49:23 <Celestar> peter1138: now for the cleanup? :D 08:54:04 <Celestar> peter1138: we're not saving the cargodest yet, do we? 08:54:30 <peter1138> Nope. 08:54:46 <peter1138> Doesn't matter yet ;) 08:55:03 <peter1138> What with 'no destination' being handled sanely now. 08:56:21 <peter1138> However, let me add that. 08:56:59 <Celestar> peter1138: just if we don't add it, we're not MP-save I'd say (= 08:57:17 <peter1138> Shh! 08:57:21 * Celestar hides 08:58:21 <peter1138> There 08:59:41 <peter1138> So basically... 08:59:51 <peter1138> We just need to do proper destination selection in UpdateStationWaiting 09:00:21 <peter1138> Oh, and patch options ;) 09:00:46 <peter1138> One option or multiple, do you think? 09:01:32 <peter1138> Passenger: On/Off, Mail: On/Off, Valuables: On/Off, Cargo: On/Off or... 09:01:51 <peter1138> Destinations: Passengers/Passengers+Mail/etc/All 09:02:00 <Kloopy> The latter makes much more sense 09:02:02 <Kloopy> To me. 09:02:19 <Kloopy> Not that you were asking. :P 09:02:32 <peter1138> Actually, I was asking. 09:02:42 <Kloopy> Hehe 09:03:19 <Celestar> peter1138: Passenger: Free, destinations, Mail: Free, destinations, Valuables/Gold: Free, maxacceptence, destinations, Other: Free, maxacceptance, destinations 09:03:23 <Kloopy> Individual settings is over complicating it, I'd suggest. Having one option with varying levels of "difficulty" just seems more sensible. 09:03:27 <Ammler> isn't it possible more generic (newcargos) 09:04:10 <peter1138> Ammler, i'd based it on the 'town effect' property, so passenger destinations would apply for both passengers and tourists, for example 09:04:33 <Ammler> specially the tourists :-) 09:04:50 <peter1138> Celestar, what to do if a station is removed? 09:04:53 <Ammler> ah :-) 09:05:03 <peter1138> Just update all packets with that destination as having no destination? 09:05:19 <Celestar> peter1138: I'd say yes 09:05:26 <Celestar> peter1138: or assign a new station randomly :) 09:05:29 <Ammler> you do not have a branch at ottd for it, it seems? 09:05:48 <Celestar> Ammler: nope, once it works, it'll go into trunk hopefully :D 09:05:53 <Celestar> (together with YAPP :P) 09:06:02 <Ammler> monster commit 09:06:05 <peter1138> Ammler, it's in hg, on my PC ;) 09:06:26 <peter1138> Right, Celestar's cleanup 09:06:58 <Kloopy> They would (will) both be awesome additions. :) 09:07:36 <Celestar> peter1138: let's hope I didn't mess something up in the cleanup :D 09:07:49 <Celestar> peter1138: I'll go on cleaning the routing code 09:08:35 <Celestar> Ammler: Kloopy we still don't have decided how to work with the boost inclusion 09:08:56 <Kloopy> boost inclusion? 09:09:33 <Celestar> Kloopy: our cargodest implementation depends on boost 09:10:15 <peter1138> Celestar, as long as you cut & pasted most of it it should be fine :D 09:10:28 <Celestar> I did 09:10:29 <Kloopy> ..and what's boost? :) 09:10:33 <Celestar> and took at the arguments 09:10:49 <Celestar> Kloopy: google boost, first entry :P 09:10:50 <peter1138> GAH 09:10:56 <peter1138> That segmentation fault is still there :o 09:11:10 <peter1138> Am I missing an update? 09:11:15 <Kloopy> Aha.. :) 09:11:20 <Ammler> Celestar: boost is installed here per default... 09:11:30 <Ammler> min c++ env. 09:11:53 <peter1138> print this 09:11:53 <peter1138> = (const Order * const) 0xd7b6e0 09:11:54 <Ammler> (at least, I never did it self :-) 09:11:58 <peter1138> print this->prev 09:11:58 <peter1138> = (Order *) 0x69a9000069a9 09:12:25 <Ammler> (version 1.33.1) 09:12:31 <peter1138> (not a valid pointer) 09:12:43 <Celestar> peter1138: not that I know of 09:12:51 <Celestar> I didn't get it yet 09:13:01 <peter1138> I got it from loading a large game 09:13:37 <Celestar> peter1138: I see. I still wanna get off this ugly ugly buffersize variable somehow, or do we leave it there? 09:20:38 *** Progman [~progman@p57A1D1E3.dip.t-dialin.net] has joined #openttd 09:21:23 <Celestar> peter1138: what is SmallVector and why are we using this instead of vector? 09:23:09 <peter1138> Originally performance and ability to specify allocation chunk size 09:24:45 <peter1138> And a custom allocation method suited for where it originally went 09:28:09 * Celestar wonders whether the vehicle factors are taken into account 09:30:07 * Celestar tests it 09:30:14 *** ecke [~ecke@213.195.202.130] has quit [Quit: ecke] 09:33:52 *** ecke [~ecke@213.195.202.130] has joined #openttd 09:35:20 <ln> is there an A380 already? 09:36:17 <blathijs> What's an A380? 09:36:20 <blathijs> Airplane? 09:36:57 <ln> yes, sir. 09:37:00 <Celestar> ln: yes. 09:37:26 <ln> but in OTTD? 09:37:51 <peter1138> There's probably a GRF file containing one. 09:37:53 <Celestar> ln: yes. 09:37:59 <Celestar> ln: AvAircraft 8 contains them 09:38:19 <ln> hmm... sounds like something that one has to download and install separately. 09:38:23 *** KillaloT [~killalot@0x5738ccc3.rdnqu1.dynamic.dsl.tele.dk] has joined #openttd 09:39:11 <peter1138> Welcome to the world of add-on graphics. 09:39:27 <Ammler> ln: never used GRFs yet? 09:39:41 <ln> Ammler: sure, the tram grf. 09:40:15 <ln> but I don't see why an A380 could not be integrated into the standard OTTD. 09:41:34 <Ammler> trams aren't integrated too, just disbributed with it... 09:41:46 <Ammler> !s/too/either/ 09:42:33 <Celestar> ln: if you get the authors permission to include it (= 09:43:22 <Ammler> Celestar: not sure IF that would be enough :-) 09:44:03 *** Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd 09:46:10 <peter1138> ln, because we don't change the default vehicles. 09:47:14 <ln> peter1138: i'm not talking about changing but adding new. 09:48:15 <peter1138> We don't do that either. That would mess up savegames as IDs would change. 09:48:28 <peter1138> And, of course, because NewGRF is there to do that job. 09:48:49 *** fmauNekAway is now known as fmauNeko 09:49:32 <ln> the design is not very extendable then. 09:49:48 <Celestar> peter1138: shouldn't we .clear() the RoutingVectorList before populating it, just in case? 09:50:19 <Celestar> peter1138: I'm just including that in my cleanup 09:50:26 <Noldo> ln: which design? 09:50:37 <ln> Noldo: design of OTTD. 09:52:03 <Noldo> it is, through newgrf 09:53:26 <Ammler> ln: you sound like someone, who just joined this channel :-) 09:53:42 <peter1138> Ammler, well, ln has never paid any attention to what goes on :) 09:54:04 <peter1138> Celestar, no, it's clean by default. 09:54:15 <ln> peter1138: i have, but then i noticed it doesn't make any difference. 09:54:52 <ln> of course i know adding any new small feature requires rewriting half of the game. 09:55:09 <peter1138> Celestar, oh... Actually we could do. And then cache the list in the window, or... something. 09:56:06 <Celestar> peter1138: I se 09:56:07 <Celestar> e 10:00:25 <ln> http://users.utu.fi/lanurm/ottd/tramline2.png 10:06:45 <ln> a conversation killer 10:08:21 <Gekz_> nice. 10:15:34 <SpComb> ln! Assembly! 10:18:59 <ln> i'm not there. i was once. 10:24:56 *** Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has joined #openttd 10:25:00 *** mode/#openttd [+o Bjarni] by ChanServ 10:25:54 *** fonso [~fonso@brln-d9bacf2b.pool.mediaWays.net] has joined #openttd 10:26:56 <ln> King of Denmark! 10:27:59 *** Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has quit [Remote host closed the connection] 10:30:53 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd 10:33:23 <Celestar> peter1138: around? 10:35:09 <peter1138> Yes 10:36:02 <Celestar> peter1138: what's on the todo-list next? 10:36:22 <Celestar> peter1138: http://www.fvfischer.de/cleanup.diff <= some minor cleanups and cleaning of the debug levels 10:37:14 <Celestar> peter1138: standby there's some crap in it 10:38:32 *** Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has joined #openttd 10:38:36 <Celestar> peter1138: reload :D 10:40:16 <Celestar> hm .. I'm stuck in an infinite loop somwhere 10:40:22 <Celestar> in a very large savegame 10:40:33 <peter1138> :o 10:44:08 <Celestar> hm . 10:44:18 <Celestar> there's a station without a vertex or something :o 10:44:33 <Celestar> 293 stations, 292 caches 10:47:17 <peter1138> Hmm, how odd. 10:48:30 <Celestar> apparently 10:48:35 <Celestar> too much debug output for the time being :P 10:50:49 <Celestar> segfault 10:50:53 <Celestar> getting there :P 10:50:57 <peter1138> H 10:50:59 <peter1138> mm 10:51:15 <peter1138> I've got a save game with segfaults the moment it's unpaused ;) 10:51:24 <Celestar> openttd: /home/vici/openttd-peter/src/routing.cpp:105: void Routing_t::AddRoute(const Order*, const Order*, VehicleType): Assertion `from->GetDestination() < num_vertices(RouteNetwork)' failed. 10:51:38 *** fmauNeko is now known as fmauNekAway 10:52:54 *** fmauNekAway is now known as fmauNeko 10:52:55 <peter1138> (gdb) print this->hopcache.size() 10:52:55 <peter1138> = 465 10:52:55 <peter1138> (gdb) print from 10:52:55 <peter1138> = 588 10:53:15 * peter1138 ponders... 10:53:44 <peter1138> I'm guessing it's deleted stations 10:53:57 <Celestar> peter1138: I'm just loading a savegame 10:54:02 <Celestar> how are deleted stations there?! 10:54:03 <peter1138> Me too. 10:54:15 <peter1138> They aren't, but you'll have gaps between StationIDs 10:54:39 <Celestar> I see 10:54:41 <Celestar> let's see 10:55:19 <Celestar> just pipe the debug output and grep for the Added vertices 10:55:33 <peter1138> (gdb) print this->hopcache.size() 10:55:33 <peter1138> = 465 10:55:33 <peter1138> (gdb) print from 10:55:33 <peter1138> = 588 10:55:39 <peter1138> errDEBUG(routing, 3, "Vertex %d added to routing network for <%s> %d", vtx, buffer, index); 10:56:06 <Celestar> dbg: [routing] Vertex 291 added to routing network for 294 10:56:10 <Celestar> got it 10:56:31 <peter1138> dbg: [routing] Vertex 464 added to routing network for <unknown destination> 769 10:56:34 <peter1138> hh 10:57:33 <Celestar> peter1138: yeah we need to take the station name printing out again for add/remove vertex. it's already freed, resp. not yet allocated 10:58:20 <peter1138> ,...,...VertexDescriptor vtx; 10:58:20 <peter1138> ,...,...do { 10:58:20 <peter1138> ,...,...,...vtx = add_vertex(RouteNetwork); 10:58:20 <peter1138> ,...,...} while (vtx != index); 10:58:23 <peter1138> nasty hack :p 10:58:27 <Celestar> peter1138: that's what I did now 10:58:29 <Celestar> it's no hack 10:58:40 <Celestar> they'll be empty and reused when a station is added 10:59:00 <peter1138> hopcache size is wrong too :o 10:59:03 <Celestar> yeah 10:59:17 <Celestar> peter1138: because when you add a vertex you have to add a hopcache/dirty entry for it ;) 10:59:30 <Celestar> dbg: [routing] Vertex 172 added to routing network for 172 10:59:33 <Celestar> dbg: [routing] Vertex 173 added for empty station. Continuing 10:59:37 <Celestar> dbg: [routing] Vertex 174 added for empty station. Continuing 10:59:40 <Celestar> dbg: [routing] Vertex 175 added for empty station. Continuing 10:59:44 <Celestar> dbg: [routing] Vertex 176 added to routing network for 176 11:00:15 <Celestar> peter1138: reload: http://www.fvfischer.de/cleanup.diff 11:00:51 <Celestar> segfalt 11:00:53 <Celestar> (gdb) p this 11:00:53 <Celestar> = (Cannot access memory at address 0x11 11:00:54 <Celestar> :o 11:01:12 <Celestar> BAH 11:01:17 * Celestar rebuilds with debug 3 11:01:22 <peter1138> Your loop is wrong 11:01:37 <peter1138> Oh 11:01:43 <peter1138> No, you left a dirty.push_back in 11:01:52 <peter1138> Although that shouldn't actually break it, just add too many 11:03:01 <peter1138> Hmm 11:03:50 <Celestar> then remove the superfluous one ;) 11:04:27 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 11:06:17 <Celestar> (gdb) p order 11:06:18 <Celestar> = (Cannot access memory at address 0x11# 11:06:20 <Celestar> ?! 11:06:31 <peter1138> Still getting messed up orders? :o 11:06:39 <Celestar> the address of the pointer is wrong?! 11:07:35 <Celestar> p this->GetNextOrderCyclic() 11:07:40 <peter1138> See what i pasted 2 hours ago :p 11:07:43 <Celestar> = (Cannot access memory at address 0x11 11:07:47 <Celestar> :o 11:08:03 <Celestar> peter1138: what? :P 11:08:16 <peter1138> (gdb) print this 11:08:16 <peter1138> = (const Order * const) 0xe914d8 11:08:16 <peter1138> (gdb) print this->prev 11:08:16 <peter1138> = (Order *) 0x35ab000035ab 11:08:45 <peter1138> this->next is null 11:08:54 <Celestar> er no 11:09:00 <Celestar> p this->next 11:09:00 <Celestar> = (Cannot access memory at address 0x11 11:09:06 <peter1138> in my case 11:09:10 <peter1138> obviously 11:10:05 <peter1138> Hmm, where is order->prev set? 11:10:14 <Celestar> er.. 11:10:34 <Celestar> &v->orders[v->cur_order_index]; is NOT part of v->orders in this case :o 11:10:58 <peter1138> v->cur_order_index is out of range? 11:11:22 <Celestar> no 11:11:27 *** Ridayah [~ridayah@12-208-15-67.client.mchsi.com] has joined #openttd 11:11:29 *** LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has joined #openttd 11:11:36 <Celestar> but v->orders[v->cur_order_index] prints TOTAL crap 11:11:41 <Celestar> it doesn't point to an order 11:11:55 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd 11:12:01 <Celestar> well it points into the order pool apparently, but not onto the beginning of an order or something 11:12:04 <peter1138> Linked list, not array? 11:12:23 <Celestar> p v->orders[v->cur_order_index].dest 11:12:24 <Celestar> = 55224 11:12:39 <Celestar> p v->orders[v->cur_order_index].type 11:12:40 <Celestar> = 83 'S' 11:12:47 <Celestar> this doesn't look like a clean order for me 11:12:52 <Celestar> to me 11:13:28 <Celestar> WTH 11:13:46 <Celestar> v->orders[v->cur_order_index] doesn't point anywhere NEAR the Order pool 11:14:15 <Celestar> oh yes it does, but .. 11:14:36 <Celestar> peter1138: PASTE STORM 11:14:40 <Celestar> (gdb) p v->orders 11:14:40 <Celestar> = (Order *) 0x8434618 11:14:40 <Celestar> (gdb) p v->orders->next 11:14:40 <Celestar> = (Order *) 0x8444ec0 11:14:40 <Celestar> (gdb) p v->orders->next->next 11:14:43 <Celestar> = (Order *) 0x8444ed8 11:14:45 <Celestar> (gdb) p v->orders->next->next->next 11:14:48 <Celestar> = (Order *) 0x8444ef0 11:14:50 <Celestar> (gdb) p v->orders->next->next->next->next 11:14:53 <Celestar> = (Order *) 0x8444f08 11:14:55 <Celestar> (gdb) p v->orders->next->next->next->next->next 11:14:58 <Celestar> = (Cannot access memory at address 0x0 11:15:00 <Celestar> (gdb) p (Order *)&(v->orders[v->cur_order_index].type) 11:15:01 <peter1138> as i said 11:15:03 <Celestar> = (Order *) 0x843467e 11:15:07 *** Zahl [~Zahl@g229214104.adsl.alicedsl.de] has joined #openttd 11:15:11 <peter1138> that's a linked list, not an array 11:15:12 <Celestar> the operator[] for the Order is not working properly 11:15:25 <Celestar> isn't the [] operator overloadded for pool items? 11:15:47 <peter1138> ... 11:15:55 <peter1138> orders is a pointer to a pool item, not a pool item. 11:16:08 <Celestar> ... 11:16:19 <Celestar> cur_order_index is NOT meant to be used to access pool elements 11:16:33 <peter1138> ,...curr = v->orders; 11:16:33 <peter1138> ,...for (int skip = 1; skip != v->cur_order_index; skip++) { 11:16:33 <peter1138> ,...,...curr = curr->next; 11:16:33 <peter1138> ,...} 11:16:36 <peter1138> sort of thing 11:17:11 <Celestar> peter1138: nope GetVehicleOrder :) 11:17:25 <peter1138> Right 11:17:55 <peter1138> Maybe it'll work now ;) 11:17:57 <Celestar> GetVehicleOrder(v, v->cur_order_index); 11:20:21 <Celestar> peter1138: can you profile the thing with: http://www.fvfischer.de/MemberZone_08_Final.sav <= profiling doesn't work for me, and no, I don't get crashes at the moment 11:20:55 * peter1138 is cleaning up things at the moment 11:21:01 <Celestar> heh ok me too :P 11:22:27 <Celestar> http://www.fvfischer.de/cleanup.diff <= here are some more things 11:24:05 <Celestar> peter1138: we're good team, aren't we? ;) 11:24:10 *** fmauNeko is now known as fmauNekAway 11:24:25 <peter1138> Tell you what... hg is way better than an svn branch for this :) 11:25:05 <Celestar> yeah 11:25:16 <Celestar> apparently :) 11:25:16 <Bjarni> hg is actually pretty good for developing purposes 11:25:44 <Bjarni> specially if two people work on the same 11:26:52 <Bjarni> can I check a diff on the nightly build server before committing it? 11:26:58 <Bjarni> without too much hassle, that is ;) 11:28:56 <Celestar> peter1138: nice cleanups, keepem comin 11:29:49 <Celestar> peter1138: the question is: does it work yet? :D 11:30:03 <Brianetta> Blast it, who decided that hashing the company passwords in RAM was funny? (-: 11:30:34 <Bjarni> not me 11:30:43 <Celestar> Brianetta: ? 11:30:46 <Bjarni> but I would have liked to claim credit for that idea :) 11:30:46 <Brianetta> Now I can't steal company passwords with a debugger 11:30:57 <peter1138> Haha 11:31:00 <Bjarni> :D 11:31:17 <Brianetta> More to the point, I can't re-set those passwords after a reload 11:31:41 <Noldo> Brianetta: re-set to what? 11:31:41 <Bjarni> isn't there an admin option to kill a password? 11:31:49 <Brianetta> There never used to be 11:31:50 <Bjarni> or will it take the whole company away 11:31:59 <peter1138> We should add one 11:32:20 <peter1138> rcon command to remove or reset a company password 11:32:47 <Brianetta> I could attach a debugger and replace the hash with a known one 11:32:56 <Brianetta> Looks like MD5, I could peek into the source to check that 11:33:17 <Brianetta> It's not like this isn't network safe (-: 11:33:48 <Ammler> Brianetta: you could also use move patch 11:33:49 <Bjarni> wouldn't it be easier to just add a function to set a company password to something specific? 11:34:25 <Brianetta> Bjarni: Actually, I'd rather remove the hash function and have a command that saved the passwords into a separate file, and loaded them from that file 11:34:39 <Rubidium> Brianetta: why aren't you able to reset the password using a debugger? 11:34:43 <Ammler> but I didn't succeed to move the server itself :-) 11:34:46 <Brianetta> So that the passwords aren't transmitted over the network loader, but *are* saved 11:35:02 <Brianetta> Rubidium: They look like MD5s 11:35:26 <Brianetta> The problem isn't replacing the password, it's saving it 11:35:40 <peter1138> Is it possible to save the hash and then reinstant that? 11:35:54 <Rubidium> save md5, overwrite md5 with saved md5 11:36:02 <Brianetta> Probably, but I only ever dumped core before. Never poked the code. 11:36:11 <Brianetta> Not while it was running 11:36:31 <Brianetta> I'd get the passwords, and save them. Reload, then attach to each company in turn and set their password. 11:36:37 <peter1138> Celestar, I'm going out 11:36:39 <Brianetta> All very clean. 11:36:46 <peter1138> So back later. 11:36:56 <peter1138> Feel free to work on destination choosing ;) 11:37:10 <Celestar> peter1138: when will you be back? (= 11:44:02 <ln> http://crap.teurasporsaat.org/?i=6529 11:45:07 <Bjarni> looks like Zimbabian dollars 11:45:25 <Rubidium> Brianetta: the idea was to store the passwords in the savegame after the hashing, it just never got implemented 11:45:36 <Bjarni> Mugabe managed to maintain an inflation of 10.000% 11:46:04 <Ammler> http://bugs.openttd.org/task/2172 <-- converting dos grfs to windows would help 11:46:25 <Ammler> would ottd need grfcodec to do that? 11:46:42 <Ammler> no, doesn't 11:47:19 <Ammler> or aren't the sprites differences that bad? 11:48:13 <Rubidium> there are more colours in the dos GRF 11:48:30 <Rubidium> which means mapping might cause strange looking buildings and such 11:48:46 <Ammler> not only the colors, also some sprites are missing, afaik... 11:49:04 <Ammler> but they aren't used anyway, I assume. 11:49:54 <Ammler> Rubidium: changing ALL grfs from windows to dos? 11:50:57 *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Read error: Connection reset by peer] 11:51:03 <Ammler> are does windows missing colors used in the dos GRFs? 11:51:33 <ln> Bjarni: the inflation is said to be 2 million per cent 11:51:42 <Ammler> we would also have problems for the NewGRFs then, i.e. MB does make all GRFs with dos 11:52:01 <Bjarni> ln: the official number is 10.000% according to their own national bank 11:52:16 <Bjarni> but some people don't trust them 11:52:24 <ln> ah, it's good to quote reliable sources. 11:52:28 *** shodan [user@ppp101-219.static.internode.on.net] has joined #openttd 11:52:37 <Bjarni> :) 11:53:21 <Rubidium> if you need to change prices several times a day due to inflation there's a big problem 11:56:02 <Ammler> don't you switch to other currency then (Euro/$...) 11:56:22 <Bjarni> they did something else 11:56:23 <Noldo> or cows 11:56:30 <Ammler> :-) 11:57:07 <Bjarni> they made their own new currency 11:57:14 <Bjarni> 1 = 10^10 of the old one 11:57:21 <Bjarni> or something like that 11:58:00 <Noldo> how does that help if you need to do that again in 2 years 11:58:23 <Bjarni> that's easy 11:58:30 <Bjarni> don't think 2 years ahead 11:58:35 <ln> who was captain kirk's first officer? 11:59:07 <Bjarni> wasn't Spock the tactical officer? 11:59:32 <Bjarni> I never really liked the TOS 11:59:41 <Bjarni> I think it's even worse than Enterprise 12:00:17 <ln> i haven't watched too much of TOS either. 12:00:27 <ln> i thought Spock was a science officer, but who knows. 12:00:45 <Bjarni> maybe he was :P 12:01:41 <Celestar> Spock was first officer 12:01:50 <ln> ok 12:01:54 <Bjarni> 2265 â As lieutenant commander, named first officer and science officer under Capt. James T. Kirk aboard Enterprise; promoted to commander soon after 12:02:22 *** LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has quit [Quit: Few women admit their age. Few men act theirs.] 12:02:56 <Celestar> he joined as science officer 12:03:17 <Celestar> after the death of Cmdr. Mitchell, Spock assumed his position as XO 12:03:27 * Celestar notices that he read/watched/played too much Star Trek 12:03:39 <Bjarni> played? 12:03:48 <Celestar> there have been games 12:03:49 <Bjarni> cosplay? :P 12:04:17 <Celestar> is there not a simple function to obtain the house population? 12:04:25 <Celestar> Belugas: you must be the expert there (= 12:04:49 * ln only has TNG, DS9 and Voyager + some of the movies on DVD 12:05:26 <Bjarni> <Celestar> is there not a simple function to obtain the house population? <-- get a tax collector to show up and then there is only one person in each house. If you donate money to the people (pay back taxes) then there are 255 people living in each building 12:06:50 *** Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd 12:07:39 *** fmauNekAway is now known as fmauNeko 12:07:51 <ln> away nicks are ok? 12:08:00 <Bjarni> not really 12:11:35 *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd 12:11:35 *** mode/#openttd [+v glx] by ChanServ 12:13:19 <Bjarni> interesting 12:13:26 <Bjarni> BBC news just sent me an email 12:13:38 <Bjarni> with a link about a story about a real UFO being found 12:13:49 <Bjarni> but the link isn't British at all 12:13:58 <Bjarni> and appears to want to execute a script 12:14:13 <Bjarni> anybody want to test it for me to figure out if it's safe to click? 12:15:16 <Ammler> Bjarni: I can, I do not have windows here :P 12:15:17 <Bjarni> I see Ammler wants to click it 12:15:54 <Bjarni> actually I was joking 12:15:58 <Bjarni> nobody should click it 12:16:27 <Bjarni> they also sent me a mail (also claimed to be from BBC) with a link of photos of Mars 12:16:31 <Bjarni> same link 12:17:05 <Bjarni> ohh and funny videos 12:17:20 <Bjarni> In New York has landed UFO. Click to see video! <-- now this is a trustworthy mail :P 12:17:59 <Ammler> hmm I do not find a dos graphics pack only. 12:18:20 * Bjarni wonders if it was written using babelfish 12:18:45 <Brianetta> Zimbabwe's inflation is being countered, in part, by having an expiry date printed on the bank notes. 12:19:04 <Ammler> Bjarni: are you aware of the desync problems with current autoreplace? 12:19:11 <Bjarni> err 12:19:18 <Bjarni> sort of 12:19:37 <Celestar> er ... 12:19:53 * Celestar wonders whether destinations is desync-safe at the moment :P 12:20:19 <Bjarni> it's safe to assume that they can desync, hence they are desync-safe :P 12:20:39 <Celestar> ok .. with a 600 vehicle, 250-station game with destinations enabled (for passengers), the CPU load on by box stays around 25% for openttd 12:20:55 <Bjarni> I know what's causing the desync and I have a half written fix for it 12:21:06 <Celestar> I don't see any noticable difference between destinations enabled and disabled 12:21:13 <Bjarni> good 12:21:17 <Celestar> now that's good 12:21:27 <Bjarni> I just said so ;) 12:21:41 <Brianetta> You all rock. 12:21:56 <Celestar> :D 12:22:04 <Celestar> now I want yapp and cargodest in trunk ASAP (= 12:22:08 <Brianetta> Makes me feel motivated. 12:22:11 <Ammler> indeed 12:22:15 <Bjarni> actually I'm more into classical and calm music 12:22:24 <Bjarni> so I prefer not to rock xD 12:22:55 <Ammler> you JAZZ 12:23:04 * Brianetta fires up the Jazz Jukebox 12:23:22 <Brianetta> Oooh 12:23:35 <Brianetta> I discovered a USB B socket on my new midi piano 12:23:52 <Brianetta> I think I can use the Roland GM2 hardware inside as a USB midi device 12:24:08 <Brianetta> I might have to have a go at using it for OpenTTD 12:24:52 <Kloopy> ..whilst keeping it hooked up to the audio player so that you can see how nice your play style sounds. :) 12:27:03 <Brianetta> http://www.roland.co.uk/digp_room_catdet.asp?ID=HPI6 12:27:40 *** Zahl_ [~Zahl@f051072254.adsl.alicedsl.de] has joined #openttd 12:27:40 *** Zahl [~Zahl@g229214104.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] 12:27:41 *** Zahl_ is now known as Zahl 12:27:57 <Brianetta> You know what makes this piano truly stand out as one where attention was paid to the design? 12:28:07 <Brianetta> There's a headphone hook near the headphone jacks 12:28:52 <Kloopy> How I misunderstood unix groups -all- this time? 12:29:00 <Kloopy> I have a group called "ibe" and I'm part of it. 12:29:10 <Brianetta> um? 12:29:10 <Kloopy> The file I'm trying to edit is owned as www-data:ibe 12:29:17 <Brianetta> ah 12:29:19 <Brianetta> yeah 12:29:22 <Kloopy> And it's chmodded 775 12:29:31 <Kloopy> But I can't write to it. 12:32:06 <Brianetta> type groups 12:32:13 <Celestar> WTF? 12:32:18 <Kloopy> Hm. 12:32:19 <Brianetta> that'll tell you what groups you're currently in 12:32:24 <Kloopy> This isn't the channel I thought it was. :) 12:32:26 <Celestar> trunk/ actually needs more CPU than cargodest on the same game :o 12:32:28 <Kloopy> :) 12:32:29 <Kloopy> But still. 12:32:36 <Kloopy> I am definitely in the "ibe" grou[. 12:32:37 <Kloopy> :) 12:32:50 <Noldo> Celestar: wwhat? 12:32:59 <SmatZ> Celestar: do you use the same cflags? 12:33:04 <SmatZ> debug, assert, ... 12:33:19 <Celestar> SmatZ: same cflags 12:33:21 <Alberth> Kloopy: 'echo "abc" >> thefile' should work 12:33:49 <Kloopy> That's the thing, it doesn't. 12:33:50 <Celestar> with a large resolution and fully zoomed out, I get around 38% with cargodest and 41% with trunk :P 12:33:58 <Celestar> might be measuring difference 12:34:08 <Celestar> long story short: it doesn't cost much 12:34:26 <Celestar> not from a CPU cycle point of view 12:34:30 <Celestar> it needs quite some memory 12:34:57 <Brianetta> Kloopy: Is your filesystem full or read only? 12:35:06 <Brianetta> Kloopy: Have you ever used the chattr command? 12:35:09 <Kloopy> Neither. 12:35:25 <Kloopy> Not on this server. 12:35:38 <Brianetta> Time to mount your fs readonly and check it for errors... 12:35:56 <Celestar> WTF?! 12:36:02 <Celestar> it also needs less memory?! 12:36:06 <Kloopy> Ah, shit... when I thought I'd logged out and in again to get my new group permissions, I'd logged out of the wrong machine. 12:36:07 * Celestar copies of openttd.cpp 12:36:10 * Celestar copies of openttd.cfg 12:36:19 <Kloopy> :/ 12:36:21 * Kloopy tool. 12:36:34 <Brianetta> Kloopy: Like I said, "groups" tells you what groups your currently logged in session is a member of. 12:36:53 <Kloopy> I was doing "groups kloopy" and not really thinking about it. 12:36:54 <Kloopy> :) 12:37:06 <Kloopy> But yes, you were right. Thanks :D 12:38:28 <Celestar> op with the same settings, CPU load on cargodest is slightly higher 12:38:37 <Celestar> (41% vs 435) 12:38:41 <Celestar> 43% 12:38:46 <Celestar> but we're leaking memory BADLY 12:38:58 <Celestar> or no. we just generate a SHITLOAD of cargopackets 12:39:47 <Noldo> :) 12:39:51 <Brianetta> How big is a packet? 12:39:58 <Brianetta> Is it one item? 12:39:59 <Celestar> ok when the number of cargopcakets increases, the CPU load goes up as well 12:40:10 <Celestar> a cargopacket? a few byes 12:40:27 <Brianetta> I mean functionally, not really 12:40:41 <Brianetta> Does it include all cargo from S to D? 12:40:58 <Celestar> it includes all cargo from S to D 12:41:00 <Brianetta> Or are there more than one packet for a given ware on a route? 12:41:04 <Brianetta> right 12:41:17 <Celestar> but only at station P or inside vehicle X 12:41:17 <Noldo> in one location 12:42:02 <Brianetta> So, the order of magnitude is n(stations)*n(stations -1)*n(vehicles) ? 12:42:21 <Celestar> of the cargopackets? yeah that's about the maximum amount 12:42:23 <Brianetta> and vehicles means each separate train wagon or rv or ship 12:43:06 <Celestar> if the unifying of same cargopackets works 12:43:11 <Celestar> which I haven't tested yet 12:43:18 <Brianetta> 150,000,000-ish packets on a game with a couple of hundred of everything 12:43:37 <Celestar> well, yes, if every thing is connected to everything else and everything is full 12:43:39 <Brianetta> I can see that causing som eload 12:43:43 <Brianetta> (: 12:44:02 <Brianetta> If I get some flash of inspiration wrt optimising that, I'll share 12:45:39 <Rubidium> Celestar: packet unifying used to work ;) 12:45:53 <Rubidium> but only when the origin and days in transport is the same 12:47:51 <Brianetta> The journey income is only aclulated upon arrival, isn't it? 12:47:57 <Brianetta> er 12:47:59 <Brianetta> calculated 12:47:59 <Celestar> Rubidium: why days in transport? 12:48:09 <fonso> I can only point to my previous idea of statistical distribution here ... 12:48:22 <Brianetta> fonso: That's a drawing board approach 12:48:49 <Celestar> Rubidium: we're mostly linear in our functions, we should just do weighted average of the days in transport 12:49:10 <Brianetta> That would work. 12:49:25 <Brianetta> In fact, once in transit, only the destination and days in transit really matters 12:49:36 <Brianetta> so you could combine start and days in transit 12:49:38 <Brianetta> and average tem 12:49:53 <Brianetta> well, you could even ignore start, once averaged in 12:50:05 <Brianetta> It would just be cargo bound for D 12:50:45 <Celestar> openttd: /home/vici/openttd-peter/src/spritecache.cpp:355: void CompactSpriteCache(): Assertion `i != _spritecache_items' failed. 12:50:48 <Celestar> WTF? 12:50:54 <Brianetta> only problem with that approach is that merging packets loses track of any "detour distance" 12:51:10 <glx> Celestar: update your repo 12:51:29 <Celestar> glx: well it's peters repo, I'll havta wait for him. but is that fixed? 12:52:05 <fonso> Another question: How is the difference corresponding to each click on an arrow in the configuration menu determined? I implemented a "max cargo per tile" setting as a uint and it always increases/decreases by 200, which is somewhat much for my taste... Of course you can click on the number and modify it manually, but I'd like the arrows to be useful. 12:52:53 <glx> Celestar: since r13869 it should be fixed 12:53:20 <Alberth> Brianetta: Just an idea: When merging cargo x days and y days old, (x > y), couldn't you make a cargo packet of x days + some negative income? 12:54:14 <Celestar> glx: k great 12:56:05 <Celestar> Rubidium: packet unifying by average days in transit has a MAJOR impact on memory usage with destinations 12:56:21 <Brianetta> Alberth: I'm not working on this patch. Also, there's a problem with any interrim loss of starting point 12:56:53 <Brianetta> If you lose starting point info, then people could keep merging cargo all over the map, and potentially get a really exaggerated income at the end. 12:57:23 <Rubidium> which is exactly the thing that I solved when I made the cargo packets 12:57:32 <Brianetta> yes 12:57:34 <Celestar> Rubidium: hm? 12:57:46 <Brianetta> the packet *requires* start, destination and days in transit. 12:57:59 <Brianetta> Only days in transit could be merged and averaged safely. 12:58:08 <Celestar> Rubidium: well, if we average it, we'll make a small mistake since dependence on days_in_transit is non-linear, but *shrugs* 12:58:57 <Celestar> but at a benefit of 50% reduction in memory usage ... 12:59:01 <Celestar> at least on large games 12:59:11 <Brianetta> If you didn't mind doing it in a lossy fashion, you could merge the start points and destinations of all inter-town packets. 12:59:23 <Celestar> since days_in_transit is almost NEVER the same 13:16:19 <Belugas> [08:01] <Celestar> Belugas: you must be the expert there (=<--- i thnk so, but i'm not sure.. been a while since i've played in that stuff 13:16:22 <Belugas> hello by the way 13:26:49 <fonso> I don't understand how the amount of goods moved to a station from nearby industries is calculated in MoveGoodsToStation. Specifically in line 2907 and 2908 in station_cmd.cpp a certain amount of goods named "moved" is transferred to a station st1, but then a different amount "t" is subtracted from the goods available. Is that intended? 13:28:08 *** tokai [~tokai@p54B802A9.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 13:29:29 <Celestar> hey Belugas (= 13:29:49 *** tokai [~tokai@p54B8030E.dip0.t-ipconnect.de] has joined #openttd 13:29:50 *** mode/#openttd [+v tokai] by ChanServ 13:30:28 <CIA-5> OpenTTD: smatz * r13891 /trunk/src/viewport.cpp: -Fix (r12547): one could click on waypoint and station signs even when they were invisible 13:30:45 <Celestar> @openttd bugs 13:30:47 <Celestar> (= 13:30:47 <DorpsGek> Celestar: Open Bugs: 41; Not assigned: 27; Closed this week: 12; Opened this week: 8 13:32:55 *** Rubidium [~Rubidium@rbijker.net] has quit [Remote host closed the connection] 13:32:58 <Brianetta> when I press X to make building invisible, and then press X again to make them come back, my station signs stop being transparent. 13:33:03 <Brianetta> This sucks. 13:39:11 *** Rubidium_ [~rubidium@sd511106a.adsl.wanadoo.nl] has joined #openttd 13:39:20 *** fmauNeko is now known as fmauNekAway 13:41:42 <Ammler> Brianetta: you can lock them with ctrl 13:42:28 <Ammler> ctrl-x for the transparency gui 13:42:35 *** Rubidium [~Rubidium@rbijker.net] has joined #openttd 13:42:35 *** mode/#openttd [+o Rubidium] by ChanServ 13:43:09 *** Rubidium_ [~rubidium@sd511106a.adsl.wanadoo.nl] has quit [] 13:44:39 <Brianetta> ah 13:45:09 <CIA-5> OpenTTD: bjarni * r13892 /trunk/config.lib: -Fix (r13863): [configure] now the SDK selection for OSX sets the default value as intended 13:47:14 *** Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has quit [Quit: Konversation terminated!] 13:47:45 *** shodan [user@ppp101-219.static.internode.on.net] has quit [Quit: Client Exiting] 13:55:33 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd 13:58:12 *** ecke [~ecke@213.195.202.130] has quit [Quit: ecke] 14:00:14 <CIA-5> OpenTTD: bjarni * r13893 /trunk/src/os/macosx/macos.mm: -Fix: [OSX] solved a deprecated warning specific to 10.5 14:04:02 *** Recimin [blabla@c-7ff1e455.98-2-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds] 14:09:40 *** Recimin [blabla@c-7ff1e455.98-2-64736c10.cust.bredbandsbolaget.se] has joined #openttd 14:10:14 *** rortom [~rortom@p57B7C126.dip.t-dialin.net] has joined #openttd 14:11:53 <dih> hello rortom 14:12:16 *** Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has quit [Quit: Leaving] 14:12:24 *** Dred_furst [~Dred_furs@user-514d7e3a.l2.c2.dsl.pol.co.uk] has joined #openttd 14:13:55 <rortom> hi 14:15:44 <Celestar> WTH 14:15:45 <Celestar> it works :o 14:16:23 <hylje> unpossible 14:16:28 <hylje> context please? 14:16:33 <rortom> paxdest? 14:16:37 <Celestar> yeah 14:16:40 <rortom> :D 14:16:52 <rortom> you guys are fast :) 14:17:40 <Celestar> payments are somewhat badly computed methinks 14:18:15 <Celestar> http://www.fvfischer.de/itworks.png 14:19:50 <rortom> very nice work! :) 14:19:58 <rortom> but it seriously needs another gui :/ 14:20:13 <Celestar> well, you can still have a less detailed output :D 14:20:26 <Celestar> I'd possibly display the nexthop only 14:21:00 <bowman> those icons with beds etc are part of paxdest? 14:21:13 <Belugas> beds are TTRS3 14:21:28 <Belugas> part of... 14:21:31 <Celestar> part of 14:21:35 <bowman> uhu... they kinda clash stylewise 14:21:35 <Yexo> nice work Celestar 14:21:44 <Yexo> do you have a patch somewhere so we can test? 14:21:54 <Celestar> bowman: they're only visible when the buildings are not displayed 14:21:57 <Celestar> Yexo: sure 14:21:59 <bowman> mkay 14:22:08 <Celestar> http://217.151.109.167:8000/ <= there, you need mercurial/hg however 14:22:18 <Yexo> that's no problem :) 14:22:54 <Kloopy> You'll need a big brain to be able to cope with working out all those routings, Celestar! :) 14:22:59 <Celestar> I can'T believe that we did the whole thing (mostly) in less than a week :P 14:23:12 <Celestar> Kloopy: it works nicely when you only think about nexthops 14:23:12 <Celestar> :) 14:23:19 <hylje> maybe a neat destination map (of connected stations) with beam strength indicating the fraction of people destined that way 14:23:31 <bowman> hehe 14:23:32 <Celestar> hylje: we have this partly already (= 14:23:40 <hylje> indeed, hence suggesting that 14:23:40 <Celestar> just the beam width is missing :P 14:23:41 <rortom> i requests screenshots :) 14:23:45 <Kloopy> So Celestar, cargo chooses a route to be taken rather than just a final destination? 14:24:27 <hylje> no transfers 14:24:31 <hylje> no intermediate stations 14:24:34 <hylje> final destination 14:25:17 <Celestar> rortom: http://www.fvfischer.de/screeny.png <= here is another screenshot of said map :) 14:26:16 <Kloopy> That graph is cool! :) 14:26:22 <Kloopy> the network graph. 14:26:24 <Celestar> I have no chance whatsoever to get rid of all my passengers 14:26:39 <Kloopy> Just needs buttons to turn various things on and off a bit like you can on the world map. 14:26:49 <Kloopy> Oh, it does. 14:26:57 <Kloopy> I really should check before I talk. :/ 14:27:58 <hylje> it just needs beam strength 14:28:18 * Belugas listens to Peter Gabriel - Signal To Noise 14:28:18 <Kloopy> Celestar: Is there any way to remove a station from a "network"? ie if I either accidentally send a train to the wrong station or I want to remove a station from my network for some reason? 14:28:25 <rortom> wow, thats nice 14:28:30 <rortom> and that in a week 14:28:41 <rortom> astonishing 14:29:16 <Celestar> Kloopy: the network depends on the orders that the vehicles have, not the stations the vehicles run into accidently 14:29:21 <hylje> they just need some motivation 14:29:23 <Kloopy> Awesome. 14:29:30 <rortom> are the tree walk calculations threaded? 14:29:47 <Kloopy> How often are the vehicle orders analysed to calculate networks? 14:29:57 <Yexo> Celestar: any idea how you'll handle non-"non-stop" orders? 14:30:40 <Celestar> Yexo: not at all up to now 14:30:53 <Celestar> Yexo: Eddi|zuHause3 has suggested an autofill feature or something 14:31:38 <Yexo> aha, effectively tranforing all "stop" orders to "non-stop" 14:32:11 <Yexo> bah, cloning the repository takes long :p 14:32:49 <CIA-5> OpenTTD: smatz * r13894 /trunk/ (Makefile.in configure): -Fix: bashisms in configure and Makefile.in 14:32:53 <hylje> large repo is rather large 14:32:59 <rortom> uhm 14:33:08 <rortom> is paxdest only meant for passengers? 14:33:38 <rortom> or should it be able to transport cargo as well? 14:33:41 <Kloopy> I believe it will have a patch setting for all cargo. 14:33:56 <hylje> all cargo eventually, but pax for now 14:34:28 <rortom> that would greatly improve the gamepay if coupled with a new cost/price design 14:34:34 <rortom> *gameplay 14:34:44 <hylje> contracts 14:34:58 <rortom> :D 14:34:59 <Celestar> rortom: currently only passengers and mail. but I can/will be expanded to all cargo types 14:35:06 <rortom> very nice :) 14:35:15 <rortom> too bad i have no time to test/contribute :( 14:36:05 <hylje> contracts could make the game much more versatile but on the other hand a lot less TTD 14:37:36 <hylje> (versatility comes namely from the terms contracts can actually impose) 14:38:06 <rortom> mhm 14:38:32 <rortom> i think this would be optional, so the user decides? :) 14:38:38 <hylje> that's a given 14:43:01 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has quit [Quit: Leaving.] 14:43:08 <CIA-5> OpenTTD: belugas * r13895 /trunk/src/music_gui.cpp: 14:43:08 <CIA-5> OpenTTD: -Codechange: Replace numbers with Colours enum on music gui and on DrawFrameRect calls 14:43:08 <CIA-5> OpenTTD: -Fix: a few misalignements 14:43:58 *** GoneWacko [~foo@adsl-58.35.Static.ssp.fi] has quit [Remote host closed the connection] 14:49:18 <Celestar> oh dear 14:49:24 <Celestar> you need insane amounts of buses for this :P 14:49:35 <Gekz_> O.o 14:49:36 <Gekz_> go to sleep 14:49:38 <Gekz_> because I'm about to 14:49:46 <Celestar> Yexo: did the checkout work? 14:50:01 <Yexo> yep, but I needed to install boost, and have some problems installing that 14:53:03 <Yexo> is there any environment variable I can set for the includedir? 14:54:20 *** tokai [~tokai@p54B8030E.dip0.t-ipconnect.de] has quit [Quit: icebears... take care of them!] 14:59:07 <Eddi|zuHause3> hm... i have 10°C spare, anyone interested in buying them off me? 14:59:25 <ln> _o/ 14:59:40 <Eddi|zuHause3> ~~~ 15:00:38 *** Purno [~Purno@5350931D.cable.casema.nl] has joined #openttd 15:01:41 <Celestar> Yexo: what system are you on? 15:01:44 <Celestar> Eddi|zuHause3: :P 15:02:00 <Yexo> cygwin 15:03:02 <Eddi|zuHause3> that should be the next trend on ebay... after WLAN cables and graphics card packaging... 15:03:07 <Eddi|zuHause3> and air guitars... 15:03:32 <Eddi|zuHause3> when having paxdest, the number of generated passengers needs to be reduced 15:04:08 <Eddi|zuHause3> with an average of 3 rides per passengers, you can only handle 1/3 the amount of passengers with the same network 15:04:30 <glx> Eddi|zuHause3: what are graphics card packaging? 15:04:48 <Eddi|zuHause3> glx: the box that the graphics card came in 15:05:04 <glx> they send empty boxes? 15:05:25 <Eddi|zuHause3> yeah, and some idiots buy them as if there was a graphics card in :p 15:06:35 <Celestar> http://www.fvfischer.de/cargodisplay.png 15:08:37 <Eddi|zuHause3> how do they pack 50 people in such a tiny [but oversized] bus? 15:09:23 <Gekz_> erm Celestar 15:09:24 <Celestar> Eddi|zuHause3: you know that a normal city bus takes up to 120? 15:09:30 <Celestar> Gekz_: ? 15:09:31 <Gekz_> is that part of your passenger destinations trialling? 15:09:32 <hylje> bogeyed buses here eat some 100 passengers 15:09:44 <Celestar> double-jointed buses up to 180 15:09:44 <hylje> up to 250 for bi-articulated 15:09:53 <Celestar> Gekz_: yes 15:10:03 <Eddi|zuHause3> that bus does not look like it has a bogey... 15:10:05 <Gekz_> Celestar: will it be, well, less ugly 15:10:10 <Gekz_> in the future 15:10:14 <Celestar> Gekz_: what is ugly? 15:10:23 <hylje> Eddi|zuHause3: the lack of a bogey doesn't magically cut its length and capacity in half 15:10:25 <Gekz_> all the (en-routes) 15:10:32 <Celestar> Gekz_: you can hide them (= 15:10:43 <Celestar> this is for debugging you network 15:10:46 <Gekz_> can they at least be organised. 15:10:47 <Gekz_> ? 15:10:48 <Celestar> and our code 15:10:54 <Celestar> they are. by cargo packet id (= 15:10:55 <hylje> the bit-destinations might get dumped to a graph 15:11:05 <Gekz_> Celestar: in the future, will it be more special? 15:11:06 <hylje> if Celestar and others arse enough to do that 15:11:24 <Celestar> Gekz_: I'm open for suggestions ... 15:11:26 <Eddi|zuHause3> we should have speed limits in cities 15:11:46 <Gekz_> Celestar: make buttons to sort alphabetically 15:11:52 <Gekz_> and by most passengers 15:12:16 <Celestar> Gekz_: will certainly not happen before the main part of cargodest is in trunk 15:12:22 <Gekz_> Celestar: I know 15:12:25 <Gekz_> I wasnt asking now 15:12:28 <Celestar> Gekz_: next focus will be how it handles multiplayer 15:12:31 <Gekz_> I was asking to put it in the back of your mind 15:12:52 <Eddi|zuHause3> for a highly connected network, i expect the "from A to B" part to be almost unique 15:12:58 <hylje> how about doing away with a big list shown by default and having that beam-strength map as the default 15:13:16 <Eddi|zuHause3> means you'll get like 50 lines of different "from A to B" for such a bus 15:13:18 <Gekz_> beam strength? 15:13:34 <hylje> yeah, based loosely on the current network graph (station connections) 15:13:39 *** frosch123 [~frosch@frnk-590fee31.pool.einsundeins.de] has joined #openttd 15:13:47 <Gekz_> I see, 15:13:49 <hylje> the more people go there of all people, the bigger the beam between two stations 15:14:23 <Celestar> Eddi|zuHause3: quite yes. however, passengers will be loaded grouped ;) 15:14:54 <Celestar> they're also generated in groups 15:15:15 <Celestar> I'm just pondering whether to generate them fractionally 15:15:18 <Eddi|zuHause3> not for long distance busses, the driver will ask each one individually where he wants to go, and sell him a ticket :p 15:15:20 <Celestar> and just display the integer ones 15:15:42 <Eddi|zuHause3> Celestar: you mean the fractions will accumulate over time? 15:16:03 <Celestar> Eddi|zuHause3: yes, but if you have [n pax to A] and [m pax to B], n will be loaded before m (in case they can both board by routing) 15:16:06 <Eddi|zuHause3> and after 100 ticks you'll have a full passenger to that city on the other end of the map? 15:16:08 <Celestar> Eddi|zuHause3: yes something like that 15:16:22 <hylje> statistics work that way 15:16:38 <Celestar> Eddi|zuHause3: but then fractionals .. 15:26:08 <Eddi|zuHause3> hm... i have a really weird graphics bug... and i'm not sure if it has anything to do with my patches... 15:26:25 <Eddi|zuHause3> i have a road with a catenary pylon... 15:28:23 *** svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd 15:28:23 *** svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer] 15:28:47 * Belugas works on a fraudulous use of a credit card at one of his customer's site :) 15:28:57 <Belugas> there's a guy who is going to have some REAL problems! 15:29:36 <SmatZ> good :) 15:35:38 *** dragonhorseboy [4a396fef@67.207.141.120] has joined #openttd 15:35:40 <dragonhorseboy> hey 15:39:21 *** skidd13 [~skidd13@p548A6A6D.dip.t-dialin.net] has joined #openttd 15:39:23 *** skidd13 [~skidd13@p548A6A6D.dip.t-dialin.net] has left #openttd [] 15:39:36 <dragonhorseboy> another quiet day here it would seem :p 15:42:39 *** dragonhorseboy [4a396fef@67.207.141.120] has left #openttd [] 15:44:37 <Ammler> just to be sure, converting a dos grf to win: grfcodec -dp1 dos.grf && grfcodec -ep2 win.grf ? 15:44:50 <DaleStan> Nope. 15:45:08 <DaleStan> -p has no effect for encoding. 15:45:10 * Celestar wonders whether cargodest compiles with YPP :D 15:45:13 <Celestar> yapp* 15:45:23 <Ammler> oh, m then? 15:45:40 <DaleStan> -m, yes. But only once, or you'll get it double-converted. 15:46:00 <Rubidium> Ammler: still doesn't magically change the dos checks in the grfs to windows checks 15:46:00 <Celestar> peter1138: http://www.fvfischer.de/packetmerge.diff 15:47:36 <Rubidium> Celestar: nice way of resetting the days_in_transit when small amounts of packets get into a station at a time 15:47:42 <Ammler> I had a little glitch as I tried the dos GRFs, btw. 15:48:11 <Celestar> Rubidium: ? 15:48:21 <Ammler> ottd looks for sample.cat but I had SAMPLE.CAT, so I needed to rename 15:48:31 <Celestar> Rubidium: you mean rounding? 15:48:46 <Yexo> cp->days_in_transit + cp->count <- should be * 15:49:19 <Celestar> yeah 15:49:23 <Celestar> already corrected :D 15:49:43 <Rubidium> Celestar: 1000 * 0 + 3 * 255 => 765 / 1003 => 0 15:50:28 <Yexo> I have boost installed, the header files are under /usr/local/include/boost-1_35/boost, but I still get "boost/graph/adjacency_list.hpp: no such file or directoy" 15:50:33 <Celestar> Rubidium: we should not use integers only :) 15:51:14 <Celestar> Yexo: ./configure CFLAGS="-I/usr/local/include/boost-1_35" 15:51:47 <Ammler> this is still correct for converting original dos to win? http://www.tt-forums.net/viewtopic.php?p=217375#p217375 15:53:07 <Ammler> "TRG1.GRF: fails!" <-- still? 15:54:33 <Rubidium> well, try it 15:54:42 <DaleStan> Ammler: There is no easy way to convert GRFs that contain recolour sprites. trg1r/TRG1 are two such grfs. 15:54:47 <Rubidium> I could never be bothered converting dos -> windows or the other way around 15:54:50 <Ammler> pasky's patch isn't available anymore 15:55:12 <Ammler> Rubidium: we had yesterday the first visitor with dos grfs :-) 15:55:35 <Ammler> linking to windows graphics isn't the best solution :-) 15:56:17 <Brianetta> Dos GRFs ahve different checksums. This will basically exclude DOS palleted players from windows games. 15:56:46 <Ammler> Brianetta: no, that check does only for NewGRFs 15:56:50 <DaleStan> pasky's patch isn't available anymore <-- Well, not available unless you know which revision to diff. 15:57:20 <Ammler> I assume, that is already in? 15:57:21 <DaleStan> I don't, by the way. 15:57:25 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Quit: bbl, playing game that's incompatible with my irc client] 15:58:35 <DaleStan> It is. And has been since 0.9.6 So maybe it's not in SVN after all. 15:59:29 <Ammler> diff between dos and win original trg1: http://paste.openttd.org/38443 16:00:05 <Ammler> I expected a bigger one :-) 16:01:43 <Ammler> Brianetta: currently the client crashes, if you try to join with dos http://bugs.openttd.org/task/2172 16:05:39 <Ammler> Rubidium: converting works, but the GUI is still pink 16:07:22 <Eddi|zuHause3> <peter1138> Destinations: Passengers/Passengers+Mail/etc/All <- i'd say something like "Passengers only/Mail only/All town based cargo [pax,mail,goods,food,...]/All cargo" 16:08:24 <Celestar> heh 16:10:07 <Celestar> ok who is willing to test paxdest in a network with yapp? :P 16:10:40 <Yexo> Celestar: as soon as I get it compiling I'll try that 16:10:49 <Celestar> Yexo: where's the problem? 16:10:57 <Yexo> I get linking errors now ("undefined reference to '__assert'") 16:10:58 <Celestar> http://www.fvfischer.de/nettest.diff <= here's the required diff 16:11:12 <Ammler> Celestar: have you complete patch? 16:11:13 <Celestar> Yexo: what distro are you on? 16:11:17 <Yexo> cygwin 16:11:18 <Celestar> Ammler: have I what? 16:11:21 <Celestar> Yexo: I see 16:12:30 <Ammler> a patch against trunk 16:12:55 <Kloopy> Celestar: Is is multiplayer safe yet? 16:13:10 <Celestar> Kloopy: this is one thing I'd like to find out (= 16:13:23 <Ammler> we could setup a server if you like... 16:14:03 *** Dr_Jekyll [Dr_Jekyll@p57B0EBFB.dip.t-dialin.net] has joined #openttd 16:14:10 <Kloopy> Because I have a group of friends who are ridiculously addicted to OTTD and play a few times a week at the moment.. I'll see if I can persuade them to try it out if we play tonight. 16:14:26 <Kloopy> Which revision is that diff against? 16:14:35 *** rortom [~rortom@p57B7C126.dip.t-dialin.net] has quit [] 16:15:16 <Celestar> Kloopy: it's against the semi-official cargodest repo 16:15:22 <Dr_Jekyll> hm...i think i'm blind...i'm looking for setting up the "General behaviour change parameter" for the ECS - but where to do this? 16:15:28 <Kloopy> Ok 16:15:41 <Celestar> Kloopy: you need mercurial/hg and get it from http://217.151.109.167:8000/ 16:15:54 <Celestar> Kloopy: my diff fixing one more thing about it and adds yapp :) 16:15:58 <Kloopy> I'll have a play after hometime. 16:16:01 <Kloopy> 15 mins :D 16:16:10 <Yexo> Dr_Jekyll: have you found the newgrf config window? 16:16:29 <Dr_Jekyll> Yexo no? 16:16:40 <Dr_Jekyll> i was looking in the .cfg file 16:16:50 <Yexo> start openttd, in the main menu, "NewGRF Settings" 16:17:08 <Yexo> or in the config file just put all parameters space seperated after the grf name 16:17:56 * peter1138 returns 16:18:05 <Dr_Jekyll> ahh thx ... so i can set them separately for each vesctor? 16:18:24 <Ammler> Yexo: noaicomp server has mercurial installed btw. :-) 16:18:35 <Yexo> nice :) 16:18:44 <Yexo> so testing this is no problem then 16:19:42 <peter1138> Ah shit, I committed too much :p 16:20:01 <Celestar> peter1138: got a sec? 16:20:15 <Ammler> Yexo: Yexo 16:20:20 <Yexo> yes? 16:20:26 <Ammler> ah, :-) 16:20:27 <Dr_Jekyll> ok maybe someone could help me with my second problem: i play the rcpp with ecs - why the roadvehs all went to the same slot at a station - even if there are free ones 16:20:39 <Celestar> peter1138: http://www.fvfischer.de/packetmerge.diff <= have a look at this. If we don't do this, we produce cargopackets like there's no tomorrow on a large map 16:20:39 <Ammler> you can setup a server, if you like... 16:20:51 <Celestar> peter1138: if we do it, we get rounding errors and linearization errors 16:21:00 <Yexo> Dr_Jekyll: queueing for road vehicles only works for normal road stops, not for drive-through ones 16:21:35 <Yexo> Ammler: I'll maybe do so as soon as I have it running locally 16:21:43 <Yexo> a new subdir like noai-svn? 16:21:57 <Ammler> yeah 16:21:58 <glx> <Yexo> I get linking errors now ("undefined reference to '__assert'") <-- mingw is picky with lib orders 16:22:07 <Ammler> and port 82 16:22:14 <Yexo> ok, thx Ammler 16:22:18 <Dr_Jekyll> Yexo if i build two normal stations (and merge them) all the busses will hit only one station (the nearest to the start) 16:22:26 <glx> Yexo: what is LDFLAGS? 16:22:38 <Yexo> glx: I didn't chagne LDFLAGS at all 16:22:40 <peter1138> Celestar, uh huh 16:22:43 <Yexo> it's empty 16:22:50 <Yexo> Dr_Jekyll: can you show a screenshot / savegame? 16:22:57 <glx> I mean the LDFLAGS created by configure 16:23:05 <Yexo> LDFLAGS = 16:23:06 <Celestar> peter1138: I also hardly manage to get rid of my passengers, but that can be dealt with later 16:23:11 <Yexo> that's the line from objs/debug/Makefile 16:23:19 <Dr_Jekyll> yexo sure... just a moment 16:23:28 <glx> Yexo: make VERBOSE:=1 16:23:47 <glx> paste the ld line 16:23:48 <Ammler> Celestar: shouldn't we first test it without yapp? 16:23:57 <Celestar> peter1138: about cargo generation? What's wrong with what we currently have? Why not just bias the random number generator a little by station size and distance, but basically give the same destination to all people generated in one scoop 16:24:03 <Celestar> Ammler: as you wish. 16:24:11 <Ammler> you think, it is that stable :-) 16:24:27 <Celestar> Ammler: I'm just multiplaying cargodest and yapp 16:24:49 <peter1138> Celestar, well quite. They're generated in small enough chunks... 16:24:49 <Yexo> glx: now it worked without any errors :S 16:25:04 <Yexo> hmm, it did not 16:25:09 <Ammler> Celestar: so you have already server running? 16:25:10 <peter1138> For the rounding issue, could we use your fixed point arithmetic there? 16:25:14 <peter1138> (It needs saving though) 16:26:09 <peter1138> I assume your maths is correct, heh 16:26:23 <Yexo> glx: ottdres.o -lstdc++ -lws2_32 -lwinmm -lgdi32 -ldxguid -lole32 /lib/libz.a -o openttd.exe <- list items from the line 16:28:14 <glx> seems right (it's the same as trunk) 16:28:56 <Celestar> peter1138: it is working fine 16:29:30 <Celestar> peter1138: saving is a non-issue since we still use basic integer data types for in-memory or io. We're just interpreting them differently 16:29:32 * glx gets the sources 16:29:45 <Yexo> there are only a few functions with undefined reference: __assert, __stricmp, __wfopen, __waccess, _wunlink 16:30:07 <peter1138> Grrr, non-working ISP nameservers :( 16:30:08 <Celestar> Ammler: I have a server running 16:30:16 <Celestar> peter1138: use 129.187.45.233 16:31:05 <Celestar> peter1138: and it works totally awesome 16:31:13 <peter1138> What does? 16:32:40 <Celestar> peter1138: cargodest. in conjuction with yapp. on a network. I'm 15 years into the game, no desyncs 16:33:26 <Rubidium> part the game and rejoin ;) 16:33:33 <Celestar> Rubidium: did so 3 times already 16:33:57 <Rubidium> nice 16:34:20 <peter1138> Rubidium, oh come on, we do know what we're doing... mostly ;) 16:34:37 <Celestar> http://www.fvfischer.de/itrocks.png 16:34:57 <peter1138> Contrary to that other paxdest patch, we only add one member to the cargopacket structure in the savegame... 16:35:32 <Celestar> peter1138: I've tried a 600-vehicle, 300 station map 16:35:49 <Celestar> it works nice if we merge cargopackets by waittime 16:36:03 <Celestar> if it doesn't the memory consumption grows insane quickly 16:36:08 <peter1138> *nod* 16:36:24 <peter1138> As prissi complained would happen when we introduced cargo packets. 16:36:41 <Celestar> prissi? 16:36:56 <peter1138> Which is odd as fundamentally you still need to store all the same information... 16:36:59 <Dr_Jekyll> Yexo http://exelor.de/traffic_jam.png 16:37:08 <Celestar> with merging, we still need noticably more memory, but the cpu consumption doesn't change by any noticable level 16:37:25 <peter1138> Celestar, a Simutrans coder, and wrote a paxdest patch for OpenTTD based vaguely on that. 16:37:51 <Celestar> Simutrans needs 128 bytes per tile 16:37:52 <Celestar> .. 16:37:58 <peter1138> Ouch. 16:38:14 <Celestar> I've *tried* to generate a 1k x 1k map once 16:38:45 * Celestar sighs "I want to play" 16:38:49 <peter1138> I last played it properly when it didn't have partial screen updates 16:39:00 <peter1138> So scrolling meant it redraw everything. Scrolling was slow. 16:39:04 <Celestar> heh 16:39:14 <Celestar> I currently have 2 clients running, each needs 1% CPU :P 16:39:21 <peter1138> Actually that was in 2005, just before Hackykid wrote PBS for OpenTTD... 16:39:38 <Celestar> each needs 3% CPU, sorry 16:39:41 <Celestar> and 7MB of memory 16:39:50 <Celestar> and that's with CPU downclocked to 600MHz 16:40:00 <Celestar> but then, it's only two dozen vehicles 16:40:40 * peter1138 gets pile transport out 16:40:44 <peter1138> 23% cpu 16:41:09 <peter1138> Although that's just started, so not many packets yet. 16:42:24 <CIA-5> OpenTTD: belugas * r13896 /trunk/src/ (newgrf_gui.cpp order_gui.cpp osk_gui.cpp): -Codechange: Replace numbers with Colours enum on newgrf, order and osk guis 16:42:58 <Yexo> Dr_Jekyll: that station looks ok, can you check in your config what the value of roadveh_queue is? 16:43:37 <Celestar> peter1138: how big was Pile Transport? 16:43:38 <Dr_Jekyll> Yexo roadveh_queue = true 16:43:54 <Yexo> can you post a savegame? 16:44:04 <Celestar> me? 16:44:09 <Yexo> no, Dr_Jekyll 16:44:11 <Celestar> oh 16:44:29 <peter1138> 1024x1024 I think 16:44:37 <Dr_Jekyll> yexo i tried already all pf with and without queuing - it's all the same 16:44:50 *** Doorslammer [Doorslamme@PIPP-p-203-54-229-69.prem.tmns.net.au] has quit [] 16:44:59 <peter1138> Oh, DNS is working fine... 16:45:03 <CIA-5> OpenTTD: belugas * r13897 /trunk/src/news_gui.cpp: 16:45:03 <CIA-5> OpenTTD: -Codechange: Replace remaining numbers with Colours enum on news guis 16:45:03 <CIA-5> OpenTTD: -Fix: a few misalignements 16:45:05 <Yexo> and what happens if you delete only the station tile the vehicles are queuing for now? 16:45:09 <peter1138> I think there's some hg clones going on... 16:45:20 <peter1138> ssh is okay due to QoS... 16:45:41 <peter1138> and DNS is now okay cos i QoS'd that :D 16:45:44 <Belugas> so repetitive task... 16:45:44 <peter1138> http://svn.bucks.net/~petern/map6.png 16:45:49 <peter1138> ^ route map from pile transport 16:45:56 <Celestar> peter1138: gotta go. 16:46:08 <Celestar> peter1138: It works nicely in the network with > 1 players (for 20 years now) 16:46:46 <peter1138> Belugas: Hope you liked my little clean up ;) 16:46:48 <Celestar> peter1138: my fixed variable type is in the gamebalance branch, file fixedt.h (header-only implementation). it's very well documented. 16:46:51 <Celestar> cu 16:46:54 <peter1138> Bye 16:47:01 * Celestar smils 16:47:02 <Celestar> es 16:47:04 <Belugas> loved it, to be honest :) 16:47:24 <Dr_Jekyll> yexo then they use all the available slots but only for one time, the next truck which arrives will try to go to the nearest slot even it is full 16:47:32 <Belugas> just was not (and still am) on the "fix-this" mode :) 16:47:33 <Belugas> i' 16:47:36 *** XaT [~root@lan31-6-82-230-27-240.fbx.proxad.net] has joined #openttd 16:47:47 <Belugas> nothing 16:47:55 <XaT> hello 16:48:09 <SmatZ> hello 16:48:11 <XaT> if someone have seen this before : 16:48:12 <XaT> openttd: /srv/r13810-HFR_src/src/tile_map.h:135: Owner GetTileOwner(TileIndex): Assertion `!IsTileType(tile, MP_HOUSE)' failed. 16:48:20 <Yexo> Dr_Jekyll: then I ask again, can you post a screenshot? 16:48:31 <peter1138> Belugas: "remaining colours"... Is that the last one then? 16:48:31 <SmatZ> XaT: sure 16:48:40 <SmatZ> very likely GRF bug 16:48:42 <XaT> our server (special version : coop track sharing + pbs + daylenght) crash 16:48:42 <Yexo> XaT: yes, are you using a trunk version or some patch? 16:48:47 <XaT> yeah ;d 16:48:49 <Belugas> but am going to give those poor invisible buttons some real widgets 16:48:50 <peter1138> r13810-HFR_src doesn't sound like trunk 16:49:03 <Belugas> peter1138, yes , remainng on that file ^_^ 16:49:06 <XaT> we"v 16:49:07 <peter1138> Oh... :o 16:49:13 <XaT> we've merged 3 patch into our version :o 16:49:21 <SmatZ> err no GRF bug, that's a bit different problem :-x 16:49:30 <Dr_Jekyll> Yexo http://exelor.de/traffic_jam2.png 16:49:33 <XaT> erm? 16:49:37 * peter1138 ponders syncing with trunk 16:49:50 <Belugas> peter1138, there are more colours enum to assign after that 16:49:55 <SmatZ> XaT: I guess it is caused by track sharing... 16:50:00 <Yexo> Dr_Jekyll: I see the problem, but without a savegame I can't have a closer look at it 16:50:09 <Belugas> like the drawframerect (i think it';s the name_ 16:50:13 <XaT> yeah fore sure 16:50:49 <peter1138> 83 files updated, 2 files merged, 0 files removed, 0 files unresolved 16:50:51 <peter1138> That's good, right? 16:50:53 <Dr_Jekyll> Yexo it has to be a problem with those patch packs - when i play a game from trunk it works correct 16:51:09 *** nicfer [~Administr@168.226.106.115] has joined #openttd 16:51:18 <Yexo> aha, in that case go complain in the thread(s) from the patches you have 16:51:35 <Dr_Jekyll> Yexo there is no quick solution? nothing for me to change to make it work? (and no i can't compile my own version ;) 16:51:41 <XaT> i went to openttdcoop 16:51:47 <Yexo> Dr_Jekyll: use a trunk version :p 16:52:27 <Dr_Jekyll> *bg* thx yexo - helped me much with the parameters 16:52:28 <Yexo> that, or get the patchpack author to fix it 16:52:28 <Ammler> Celestar: you forgot to add the new files for your yapp patch 16:53:02 <nicfer> Idea for the website: why don't make it a wiki? 16:53:13 <nicfer> like Wormux's page 16:53:37 <Yexo> because we don't want any random user editing the main website 16:54:26 *** GoneWacko [GoneWacko@86-60-147-155-dyn-dsl.ssp.fi] has joined #openttd 16:54:26 <nicfer> you can protect the main site and only make editable the manuals section 16:54:27 <Dr_Jekyll> is the author from the russian community patch pack in here? yexo told me i should get you to fix my problem *hide* 16:54:40 *** nicfer is now known as Mr_Hyde 16:54:52 <Mr_Hyde> muhahahhahha 16:55:23 * Dr_Jekyll says *upps* 16:56:28 <Yexo> @seen smokey555 16:56:28 <DorpsGek> Yexo: I have not seen smokey555. 16:56:39 <Yexo> @seen smoky555 16:56:39 <DorpsGek> Yexo: smoky555 was last seen in #openttd 2 weeks, 6 days, 6 hours, 23 minutes, and 54 seconds ago: <Smoky555> 53 patches... 16:56:51 <Yexo> looks like he hasn't been here for a whiel 16:59:47 *** Mr_Hyde is now known as nicfer 17:00:55 <nicfer> a wiki page would work if the main pages (portal, downloads, etc) are protected 17:01:14 <Yexo> but if that's the case, what is the advantage of a wiki? 17:03:48 <Rubidium> but wiki's aren't quite dynamic enough 17:04:20 <Rubidium> I seriously don't want to change the wiki every few milliseconds for the server page etc. 17:04:43 <dih> XaT ? 17:04:56 *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has quit [Ping timeout: 480 seconds] 17:07:20 *** Noetloj [~105Adam@5acb31ac.bb.sky.com] has joined #openttd 17:08:03 <Noetloj> quote from the site: As there were quit some (not so small) fixes since 0.6.2-RC1 we are releasing a second release candidate, 17:08:10 <Noetloj> Should be "Quite" 17:08:22 <Noetloj> well, Q = q 17:08:29 <ln> quite from the site? 17:08:50 <Noetloj> ...yeah, I think your eye sight is a bit fail. 17:09:23 <SmatZ> hehe 17:10:00 *** Wolf01 [~wolf01@host41-160-dynamic.56-82-r.retail.telecomitalia.it] has joined #openttd 17:10:41 <Wolf01> hello 17:11:00 <SmatZ> hello Wolf01 17:14:49 <glx> Noetloj: I don't see any errors on the site 17:17:38 *** Klanticus [~Klanticus@189.35.184.72] has joined #openttd 17:17:44 <CIA-5> OpenTTD: belugas * r13898 /trunk/src/ (player_gui.cpp rail_gui.cpp): -Codechange: Replace remaining numbers with Colours enum on players, roads and rails guis 17:18:13 <Belugas> mmh 17:19:59 <CIA-5> OpenTTD: belugas * r13899 /trunk/src/road_gui.cpp: 17:19:59 <CIA-5> OpenTTD: -Codechange: Replace numbers with Colours enum on roads gui. 17:19:59 <CIA-5> OpenTTD: save command file before commiting :P 17:19:59 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Read error: Connection reset by peer] 17:23:22 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [Quit: TschÃŒÃ] 17:26:08 *** nicfer [~Administr@168.226.106.115] has left #openttd [] 17:39:52 <GoneWacko> bah, the TranslateXYToTileCoord function is confusing me 17:45:00 *** ARock [R.Rock@xdsl-87-79-208-226.netcologne.de] has joined #openttd 17:46:01 *** gregor_ [~gregor@xdsl-87-78-21-39.netcologne.de] has joined #openttd 17:46:05 <CIA-5> OpenTTD: belugas * r13900 /trunk/src/ (4 files): -Codechange: Replace numbers with Colours enum on settings, smallmaps, stations and signs guis. 17:48:27 *** gregor_ [~gregor@xdsl-87-78-21-39.netcologne.de] has left #openttd [] 17:50:49 *** Rexxars [~rexxars@62.113.133.253] has joined #openttd 17:54:27 <GoneWacko> Apart from the zoom scaling and the bits where it does all the magic with the z-coordinates, I've recreated the function in python (for easy testing), yet the values I'm getting are definately not right. :[ 17:54:58 <GoneWacko> but if I assume being zoomed in all the way and flat land at Z=0 then I shouldn't need those bits anyway. 18:14:13 *** Zuu [~Zuu@c-fd4ee055.510-8-64736c10.cust.bredbandsbolaget.se] has joined #openttd 18:14:21 <Ammler> Celestar: ? 18:14:44 *** Zuu is now known as Guest584 18:15:15 *** Guest584 is now known as Zuu 18:23:51 <Zuu> I'm looking at adding a search function to the sign list box. I think I will implement it so that if you type "BBH01" in the box it will only show signs that contains the text you have written. My first though was to make a second list of signs (array of pointers) that only contains the signs that matches the search term. However looking at station list window it uses a class GUIList that contains capabilities of having multi 18:23:51 <Zuu> ple (and selectable) sort functions. A way to go could be to try to add search/filter to that class. What do you think? - Also do you like having a search for the sign list? 18:25:13 <Zuu> Some lame screenshots of it: http://www.tt-forums.net/viewtopic.php?f=32&t=38658 18:25:38 <Zuu> (lame in the sense that I just don't draw the signs that don't match but don't comress the list) 18:30:26 *** fmauNekAway is now known as fmauNeko 18:32:29 <Ammler> that filter could also be usefull for other lists 18:32:42 <Wolf01> that's a nice feature, I don't make a so large use of signs that they need to be searched, but I think that it'll help on coop games 18:33:44 <peter1138> Zuu, well you could just modify the BuildSignsList method... 18:33:55 <Zuu> Especially when there are various amount of white-spaces before signs. So therefor I think the sign-list is of most need for a search/filter. 18:34:04 <Zuu> peter1138: Thanks for that hint. 18:34:12 <Yexo> I'd like the same feature for other lists, such as the station / town list 18:34:25 <Yexo> especially with lots of stations it'd be nice 18:35:08 <peter1138> Well, I'd say you're best off filtering as the list is built. No special extras in the base classes are needed for that, I think. 18:35:15 <Wolf01> I'll add that feature for vehicles too, it should be useful to look for vehicles which can carry the searched cargo 18:35:21 <peter1138> FOR_ALL_SIGNS(si) *this->signs.Append() = si; 18:35:23 <peter1138> -> 18:35:37 <peter1138> FOR_ALL_SIGNS(si) if (si matches filter) *this->signs.Append() = si; 18:35:55 <Zuu> I will begin with the sign list though and move on from there. 18:36:00 <peter1138> *nod* 18:36:32 <peter1138> Did you find a solution for windows having no such thing as focus? 18:37:42 <Zuu> Not enterly yet. I have though of how to solve it. I think I will hide the search box by default so users must enable it. Or we have to lock the arrow keys whenever a window with search is open. 18:38:41 <Zuu> From code point of view it might be best to use a seperate window for searching as it need to be in the very begining of key-input proces. Or auto-rail will steal the a-key for example. 18:40:02 <Zuu> Something like the on-screen-keyboard but for searching. Have not yet tested if OSK can be typed in. Might be possible to use it stright away. And have a hidden editbox that is passed as argument to OSK. 18:40:07 *** ARock [R.Rock@xdsl-87-79-208-226.netcologne.de] has quit [] 18:42:07 <Zuu> Doesn't look like the OSK takes input, or at least it seams to be after sign window in key-reading-sequence. 18:46:07 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd 18:46:26 <fonso> I implemented station capacities 18:46:29 <fonso> but its a cheat 18:46:37 <fonso> :( 18:47:04 <fonso> You can build a station of very small capacity and then let large vehicles go there repeatedly. 18:47:25 <fonso> Thus they won't be able to unload anything, but they'll still get transfer credits 18:47:34 <Ammler> peter1138: is there really need to enable/disable cargo destination for different cargo types? 18:47:54 <peter1138> Yes. 18:48:24 <fonso> Is anyone actually interested in station capacities? 18:48:34 *** LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has joined #openttd 18:48:58 <SmatZ> fonso: maybe as GRF feature 18:49:06 <peter1138> fonso, ... what SmatZ said. 18:49:25 <peter1138> Yeah, if NewGRF will control it, probably with callbacks, then it's great. 18:49:31 <fonso> even as GRF feature that would be a principal problem 18:50:05 <peter1138> Transfer credits aren't much use without the final destination. 18:50:45 <fonso> eventually the people will get off the vehicle even at their origin station if you just drive in circles long enough 18:51:12 <Ammler> peter1138: one little thing I just realized, if you use a dedicated airport as hub for a region, which doesn't self accept passengers, you will have passenger there all the time... 18:51:18 <fonso> but you've ripped them off pretty well until then 18:52:29 <Zuu> peter1138: Is there really a BuildSignsList? I fail to find it using grep in * or */* or */*/* also I looked at CmdRenameSign, there it simply set _sign_sort_dirty = true so that sign window later calls GlobalSortSignList() that sorts the list. - Stations have BuildStationList and is using GUIList. But Signs don't use GUIList and don't have a BuildSignsList function. 18:52:30 <Yexo> hmm, I now get "/usr/include/boost-1_33_1/boost/config.hpp:35:33: /usr/include/boost-1_33_1/boost/boost/config/compiler/gcc.hpp: Too many levels of symbolic links" 18:52:54 <Ammler> http://img11.myimg.de/cargodest0b6ad.png 18:53:51 <Yexo> sorry, that was my fault 18:54:11 <Eddi|zuHause3> symlink to itself? 18:54:14 <Yexo> (why did I only see the error after posting it?) 18:54:17 <Yexo> Eddi|zuHause3: yes ;) 18:54:58 <Eddi|zuHause3> Ammler: so what is your problem? 18:55:11 <Ammler> Eddi|zuHause3: the screen? 18:55:39 <Ammler> you see there "...to 3Town" but 3Town doesn't accept pass 18:55:40 <Yexo> woot, I have cargodest compiled now :) 18:56:22 <Eddi|zuHause3> that's probably the random destination choosing not checking if the destination actually accepts the cargo 18:56:25 <Ammler> as 3town is something like the airport for those 3 town in that region 18:56:45 <Eddi|zuHause3> as i understand it, that part is very rudimentary 18:57:21 <Ammler> well, it rocks (jazz) :-) 18:57:38 <Eddi|zuHause3> it jazzs? 18:57:56 <Ammler> yeah, celestar doesn't rock 18:58:31 <Eddi|zuHause3> no, that was bjarni 18:58:42 <Ammler> :-) 18:58:55 <Ammler> indeed, sorry :-) 18:59:13 <Eddi|zuHause3> <Celestar> http://www.fvfischer.de/itrocks.png 18:59:59 <Ammler> nice part is, you can use existing saves and they are "fast" converted to cargo dest... 19:00:58 <Eddi|zuHause3> so... what magical incantation do i use to get started with mercurial? 19:01:13 <Eddi|zuHause3> i mean after "yast -i mercurial" 19:01:27 <Ammler> hg clone <url> 19:01:38 <Ammler> that all :-) 19:02:08 <Ammler> it seems like svn with update and revert 19:02:46 <Eddi|zuHause3> can i add that to an existing checkout? 19:03:40 *** svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd 19:03:40 *** svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer] 19:04:36 <Ammler> http://www.ivy.fr/mercurial/ref/v1.0/ <-- helpful 19:05:49 *** Progman [~progman@p57A1D1E3.dip.t-dialin.net] has quit [Remote host closed the connection] 19:09:19 *** ecke [~ecke@21.161.broadband7.iol.cz] has joined #openttd 19:11:02 <Eddi|zuHause3> it's taking forever... 19:14:46 <Ammler> yep, it doesn't "just" download the files, the whole history, afaik 19:15:08 <Rubidium> oddly enough a hg repo with history is smaller than a svn checkout 19:16:28 <Ammler> cargodest is 84MB here 19:18:57 <Eddi|zuHause3> i should use the time to check where the old patch hooked that "reduce passenger numbers" option ;) 19:19:43 <CIA-5> OpenTTD: smatz * r13901 /trunk/Makefile.src.in: -Fix: make sure REV_NR isn't empty, rev.cpp would fail to compile 19:23:00 <Eddi|zuHause3> "/* first eventually reduce the number of passengers */" <- that sentence does not make sense... 19:23:29 <Eddi|zuHause3> "first" and "eventually" are opposite things in my mind... 19:23:41 *** Klanticus_ [~Klanticus@189.35.184.72] has joined #openttd 19:23:41 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd 19:26:14 <fonso> Well, here is station capacities: http://www.tt-forums.net/viewtopic.php?f=33&t=38712 19:26:43 <peter1138> Ammler, yes, destination selection is not in place yet. It is just random at the moment. 19:26:47 <Eddi|zuHause3> this code is totally insane... 19:26:53 <peter1138> Eddi|zuHause3, that may also be because it's at the end of my ADSL line... 19:27:22 <Eddi|zuHause3> peter1138: want to bet that my down bandwidth is lower than your up bandwidth? :p 19:28:18 <peter1138> My up is 448 kbit/s 19:28:24 <Eddi|zuHause3> see ;) 19:28:33 <Eddi|zuHause3> my down is 384 kbit/s ;) 19:28:36 <peter1138> Thank the Lord of QoS, I can still use SSH nicely ;) 19:28:41 <peter1138> Ouch... 19:28:53 *** Klanticus__ [~Klanticus@201-43-57-195.dsl.telesp.net.br] has joined #openttd 19:30:47 *** Klanticus [~Klanticus@189.35.184.72] has quit [Ping timeout: 480 seconds] 19:32:05 <Ammler> I am also wondering,why so many complain about ECS closing, I run now 20 years a map without any problems there.. 19:32:26 *** Klanticus_ [~Klanticus@189.35.184.72] has quit [Read error: Connection reset by peer] 19:33:21 <Eddi|zuHause3> i can't run ECS maps... 19:33:42 <Eddi|zuHause3> 2kx2k with very few industries totally choke my system 19:34:05 <Ammler> well, I play only with 256² 19:35:05 <Eddi|zuHause3> problem appears to be, that the industry amount generated is per industry type, not over all industries, so when you have 20 industry types instead of 10, you get twice the amount of industries 19:35:27 <Eddi|zuHause3> so you get way too many industries to start with... 19:35:59 <Ammler> I have only 2 vectors loaded, that might be the problem then :-) 19:36:57 <Ammler> is there a difference between tranfer and unload in cargodest? 19:37:03 <Ammler> s 19:37:48 <Eddi|zuHause3> transfer is useless 19:38:00 <SmatZ> what about transfer credits? 19:38:10 <SmatZ> or is it handled for unload, too? 19:38:18 <Ammler> SmatZ: yep 19:38:23 <Ammler> well, it looks like 19:38:27 <Eddi|zuHause3> 1 out of 3 hunks FAILED -- saving rejects to file src/misc_gui.cpp.rej :(( 19:38:33 <Ammler> I see green and yellow msg together :-) 19:38:43 <Rubidium> some's merging yapp? 19:39:22 <SmatZ> in trunk? 19:39:35 <Eddi|zuHause3> Rubidium: i tried to apply Celestar's patch to the paxdest thing 19:39:38 <peter1138> Where? 19:39:46 <Rubidium> nah, looks like Eddi|zuHause3's is doing that locally 19:39:57 <peter1138> Eddi|zuHause3, oh, my repo has been synced with trunk since then. Sorry. 19:40:13 <peter1138> You can try going back some revisions, but I have no idea how :) 19:40:24 <SmatZ> hehe 19:40:45 <Eddi|zuHause3> it's just some widget sizes, it appears 19:42:42 <peter1138> Ooh, a PM from SirkoZ. 19:42:48 <peter1138> Whoops, I hit the delete button :o 19:43:25 *** Purno [~Purno@5350931D.cable.casema.nl] has quit [Read error: Connection reset by peer] 19:43:34 <Eddi|zuHause3> what's his problem? 19:45:18 <fonso> Celestar: Do you have any more feedback for diagonal levelling and demolishing, yet? Or anyone else who might have had a look at it? 19:45:18 *** KillaloT [~killalot@0x5738ccc3.rdnqu1.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer] 19:46:36 <Belugas> [15:39] <@peter1138> Ooh, a PM from SirkoZ. <--- poor you, i sympatize :) 19:46:54 <Eddi|zuHause3> fonso: try not to push too much ;) 19:47:07 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd 19:47:31 <Eddi|zuHause3> hm... yapp new files... i don't really have a current yapp around... 19:47:53 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [Read error: Connection reset by peer] 19:48:16 *** KillaloT [~killalot@0x5738ccc3.rdnqu1.dynamic.dsl.tele.dk] has joined #openttd 19:48:31 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd 19:48:37 *** welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has joined #openttd 19:51:03 <Eddi|zuHause3> feature request: transfer credit should be x% less than the current value, to account for expected waiting times 19:51:41 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [] 19:57:38 <Ammler> are there any idea's how to handle the cargo destinations? 19:58:12 <Ammler> how to distribute 19:58:39 <Zuu> Is't "Sign* const *search_result;" a pointer to a const Sign* or is it the other way around? 19:58:48 <peter1138> There are ideas, yes. 20:01:24 <Ammler> :-) 20:04:15 *** Klanticus__ [~Klanticus@201-43-57-195.dsl.telesp.net.br] has quit [Remote host closed the connection] 20:09:43 <Eddi|zuHause3> Zuu: if you really need such a line, you are probably doing something very wrong 20:10:07 <CIA-5> OpenTTD: smatz * r13902 /trunk/Makefile.src.in: -Fix (r13375): rev.cpp wasn't recreated when --revision was used and the 'modified' status of sources changed 20:13:13 <Zuu> Eddi|zuHause3: I was wrong in that what I wanted is not typed as I wrote it. But it looks like _sign_sort is a dynamic array of const pointers. 20:13:32 <Zuu> static const Sign **_sign_sort; 20:14:24 <Zuu> So then I need to declare my search_result in a similar manner. (const Sign ** search_result;) 20:15:13 <Zuu> Or I get cast error when I assign search_result[j] = _sign_sort[i] 20:32:14 *** TrueBrain [truelight@80.247.163.110] has joined #openttd 20:35:39 <peter1138> Zuu: _sign_sort does not exist any more. 20:35:46 <Zuu> Not? 20:35:54 <Zuu> So you have changed it recently? 20:36:17 <Zuu> (last week) 20:36:35 <peter1138> Two days ago. 20:36:47 *** rortom [~rortom@p57B7C126.dip.t-dialin.net] has joined #openttd 20:36:54 <Zuu> Oh.. well, some coding experience at least :) 20:36:58 <TrueBrain> Expect web-related problems: DNS update in progress (can take up to an hour before it is at your client :)) 20:37:52 * Zuu detects no problems at openttd.org :( 20:37:57 <Zuu> :p 20:38:06 *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Ping timeout: 480 seconds] 20:38:08 <TrueBrain> depends on which subdomain you are surfing :) 20:38:24 <Zuu> only tried nightly.openttd.org 20:39:28 *** svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd 20:39:28 *** svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer] 20:41:33 <TrueBrain> and that is one of the few not changing this night :) 20:43:12 <Zuu> hmm, wiki.openttd.org works, what's more to try? ;) 20:43:24 <TrueBrain> svn.openttd.org? :p 20:43:28 <Belugas> svn, hg, blog,... 20:43:44 <Belugas> bugs 20:43:49 <Zuu> Ok, that don't work. 20:43:55 <Belugas> boobs 20:43:57 <Belugas> mmh.. 20:44:00 <TrueBrain> like, nobody can commit currently ;) 20:44:02 <Belugas> never workd... 20:44:07 <Prof_Frink> norks.openttd.org ? 20:44:09 <Belugas> boohooo.... 20:44:21 <Belugas> kick.openttd.org 20:44:31 <Prof_Frink> Belugas: http://www.owenrudge.net/various/n37108819_32387967_8981.jpg 20:44:41 <Zuu> but bugs and hg works :) 20:44:56 <peter1138> !norks 20:44:57 <TrueBrain> Zuu: then you already had the DNS update ;) 20:45:01 *** frosch123 [~frosch@frnk-590fee31.pool.einsundeins.de] has quit [Remote host closed the connection] 20:45:01 <Belugas> that's you Prof_Frink? shold go on a diet :) 20:45:16 <Prof_Frink> No, that's orudge's norkular friend. 20:46:01 <Belugas> right... 20:46:26 <peter1138> Hmm, hg no longer redirects to port 8000... 20:47:11 <Eddi|zuHause3> so... reducing passenger numbers... important... 20:47:16 <TrueBrain> peter1138: one of the chances ;) 20:47:40 <peter1138> What is serving that? 20:48:56 <Eddi|zuHause3> hm... some trains are leaving empty even though 1500 passengers are waiting... 20:54:05 <SmatZ> peter1138: FS#2172 - kais58's problem was solved by switching to WIN grfs, but the fact that OTTD crashes with segfault isn't very nice... 20:54:18 <peter1138> That's not *solved* 20:54:29 <peter1138> That is a workaround. 20:54:35 <SmatZ> peter1138: and the task isn't closed 20:56:35 <peter1138> Well that's something :p 20:57:34 <TrueBrain> if you do it correctly, http://svn.openttd.org/ <- this should give one hell of an ugly page 20:57:55 * peter1138 wonders if the station view should toggle between just cargo type, sources and destinations, and just destinations shown. 20:58:25 <peter1138> There's a bit too much information there currently. 20:58:38 <peter1138> TrueBrain, ugly? No, it's nice plain HTML :D 20:58:44 <TrueBrain> peter1138: well, okay okay :p 20:58:45 <TrueBrain> @op 20:58:46 *** mode/#openttd [+o TrueBrain] by DorpsGek 20:58:57 <peter1138> Although somewhat invalid HTML. 20:59:02 *** TrueBrain changed the topic of #openttd to: 0.6.1 | Website: *.openttd.org (Translator: translator2, Gameservers: servers, Nightly-builds: nightly, WIKI: wiki, Dev-docs: docs, Patches & Bug-reports: bugs, Revision log: vcs) | #openttd.notice for FS + SVN notices | UTF-8 please | No Unauthorised Bots | We Love YAPP 20:59:18 <TrueBrain> http://vcs.openttd.org/svn/ <- still I find that more readable :p 20:59:31 <peter1138> Oh, that's where it's hidden. 21:00:00 <TrueBrain> well, trac was long gone .. it is back since today :p 21:00:22 <peter1138> Are the performance problems fixed, or is it too soon to know? 21:00:48 <TrueBrain> too soon 21:00:54 <TrueBrain> but it feels fast :) 21:00:59 <TrueBrain> else you can always use: 21:01:05 <orudge> nice work on the cleanup, there 21:01:06 <TrueBrain> http://vcs.openttd.org/hg/ 21:01:07 <TrueBrain> or 21:01:07 * orudge is just reading the e-mail 21:01:09 <TrueBrain> http://vcs.openttd.org/git/ 21:01:30 <orudge> hmm, so both hg and git are running on there? 21:01:32 <rortom> peter1138: that calls for a station gui update ;) 21:01:51 <TrueBrain> orudge: 'running' is a big word, but they are readable from there :) 21:01:56 <orudge> heh 21:02:05 <TrueBrain> for the german people: https://secure.openttd.org/vcs/svn/ 21:02:13 <orudge> ooh, and trac is back 21:02:13 <orudge> yay 21:02:41 *** KritiK [~Maxim@78-106-214-150.broadband.corbina.ru] has joined #openttd 21:02:42 <peter1138> Why German? 21:03:14 <TrueBrain> or sweden .. which country now can do random taps on people their connection? :) 21:03:27 <rortom> haha :p 21:04:07 <Wolf01> 'night 21:04:14 *** Wolf01 [~wolf01@host41-160-dynamic.56-82-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.] 21:05:00 <SpComb> Logs: http://zapotek.paivola.fi/~terom/logs/openttd 21:05:00 <Zuu> !logs 21:05:25 <Eddi|zuHause3> that was indeed sweeden 21:05:43 <Eddi|zuHause3> but i would not put it past the german government to follow that lead 21:06:03 *** Progman [~progman@p57A1D1E3.dip.t-dialin.net] has joined #openttd 21:06:14 *** TinoM [~Tino@i59F55DED.versanet.de] has quit [Quit: Verlassend] 21:06:31 <Zuu> Eddi|zuHause3: Through they said they will only listen to non-swedish traffic and therefor normal people will not be affected :D 21:06:48 <Zuu> non-swedish as not in swedish language 21:07:00 <Eddi|zuHause3> like... english? 21:07:06 <Zuu> for example 21:07:09 <Eddi|zuHause3> like... right now? :p 21:07:10 <Ammler> peter1138: how are stations handled which do not have vehicels in the orders? 21:07:13 <Zuu> Yep 21:07:18 * TrueBrain slaps CIA-5 21:07:25 <CIA-5> OpenTTD: rubidium * r13903 /trunk/src/masm64.rules: -Fix: missing eol-style property. 21:07:29 <Ammler> (not non-stop orders) 21:07:32 <Eddi|zuHause3> Ammler: they are ignored 21:07:45 <TrueBrain> good boy, CIA-5 21:07:49 <peter1138> Ammler: Not. 21:08:37 <Eddi|zuHause3> this is total shit... "Error: RPM failed: Command was killed by signal 11 (Segmentation fault)." 21:08:55 <Eddi|zuHause3> and apparently nobody else in the world has this problem 21:09:05 <Ammler> heh, now I see why there is need to have cargo dest controllable per type :-) 21:09:16 <TrueBrain> Eddi|zuHause3: check memory 21:09:26 <TrueBrain> :p 21:09:41 <Rubidium> heh, broken memory is my excuse line! 21:09:45 <Eddi|zuHause3> TrueBrain: memory problems would harldy be limited to RPM 21:10:07 *** welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has quit [Ping timeout: 480 seconds] 21:10:08 <TrueBrain> Eddi|zuHause3: last time I had a tons of weird segfaults and random kills .. turned out memory was bad :p 21:10:10 <TrueBrain> took a while :) 21:10:23 <TrueBrain> so I scream to you: check memory ;) 21:10:49 <Eddi|zuHause3> yes, but i do not have weird and random segfaults... it's only RPM... which is fine a few times, and suddenly segfaults 21:11:00 <Eddi|zuHause3> and has no way of recovering unless you reboot 21:11:02 <peter1138> Gah, early eGRVTS vehicles really suck :o 21:11:04 <TrueBrain> well .. get a real distro :p 21:11:25 <SmatZ> hehe 21:11:35 <Ammler> peter1138: low cap? 21:11:38 <Eddi|zuHause3> yeah yeah... 21:11:48 <peter1138> Yeah, 8 passengers at 15 mph does not help a network :) 21:12:20 <Eddi|zuHause3> 1800? 21:12:31 <peter1138> 1926 21:12:35 <Ammler> there is need for early houses too :-) 21:13:09 <Eddi|zuHause3> pre-1900 economy must be totally different... 21:14:10 <Ammler> Eddi|zuHause3: there are some nice suse channels.. 21:14:30 <Eddi|zuHause3> Ammler: where? i never found any fitting that description... 21:14:47 <Ammler> freenode 21:14:57 <Eddi|zuHause3> anyway... need to reboot... 21:15:40 *** rortom [~rortom@p57B7C126.dip.t-dialin.net] has quit [] 21:17:04 *** Eddi|zuHause3 [~johekr@p54B771CF.dip.t-dialin.net] has quit [Remote host closed the connection] 21:21:00 *** Eddi|zuHause2 [~johekr@p54B76397.dip.t-dialin.net] has joined #openttd 21:21:25 *** welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has joined #openttd 21:27:31 *** welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has quit [Read error: Connection reset by peer] 21:27:48 *** welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has joined #openttd 21:32:17 *** curson [~curzon@79-68-37-51.dynamic.dsl.as9105.com] has joined #openttd 21:33:02 *** XaT [~root@lan31-6-82-230-27-240.fbx.proxad.net] has quit [Read error: No route to host] 21:35:07 <Zuu> Will anyone get offended if I start a new thread in Dev Section about search in sign list or should I get a mod to move the existing thread in suggestions forum? 21:35:24 <Yexo> just atart a new thread 21:36:45 <Zuu> Ok 21:38:34 <TrueBrain> And a notice for everyone: git and hg repos are moved, and under a new URL. Either use: https://secure.openttd.org/git (or hg), or http://git.openttd.org (or hg), or git://git.openttd.org (not for hg) 21:40:28 <orudge> you should add cvs.openttd.org for completeness sake ;) 21:40:36 <orudge> and Microsoft SourceSafe! :p 21:40:45 <TrueBrain> grr @ orudge 21:40:59 <TrueBrain> I was about to type @kick orudge, but I am known to do it wrong, and really kick you :p 21:41:01 <blathijs> Perhaps this is a nice opportunity to play with hg instead of git when I go fiddling around with mempools 21:41:12 *** mode/#openttd [-o orudge] by Rubidium 21:41:14 <orudge> :( 21:41:17 <Rubidium> yes... you've been punished ;) 21:41:18 *** mode/#openttd [+o orudge] by ChanServ 21:41:18 <orudge> :) 21:41:24 <TrueBrain> blathijs: sounds like a plan :) 21:41:24 * orudge has been using git a fair bit for wine recently 21:41:31 <TrueBrain> git sucks, hg rules :) 21:41:31 <orudge> alas, it doesn't work so well on Windows 21:41:39 <TrueBrain> exactly :) 21:41:42 <orudge> and I do most of my OpenTTD-related things on Windows 21:41:57 <TrueBrain> I wonder if anyone noticed that on all new pages the OpenTTD icon is in their webbrowser ... :) 21:42:14 <orudge> not as such 21:42:17 <orudge> well, I didn't 21:42:20 <orudge> but then 21:42:22 <Eddi|zuHause2> new mempools... that task existed before i came here 21:42:28 <orudge> it was always there for openttd.org itself, I think? 21:42:30 <Eddi|zuHause2> that is over two and a half years ago... 21:42:33 <orudge> so I was probably just used to it being there for that :p 21:42:36 <TrueBrain> orudge: only for main-page :) 21:42:56 <orudge> heh, OK 21:43:17 <orudge> ah, and running lighttpd for vcs.openttd.org, good :) 21:43:28 <peter1138> $ hg pull 21:43:28 <peter1138> pulling from http://hg.openttd.org:8000/trunk.hg/ 21:43:30 <peter1138> :o 21:43:33 <peter1138> how do i change that? :o 21:43:50 <TrueBrain> .hg/hgrc 21:44:12 <TrueBrain> orudge: all front-pages use lighttpd .. sadly enough a few pages are proxies to apache 21:44:18 <TrueBrain> (some just refused to work otherwise) 21:44:24 <orudge> I see 21:44:48 <peter1138> Ah, http://hg.openttd.org/openttd/trunk.hg/ :o 21:45:17 <peter1138> Hmm, slow... 21:45:47 <TrueBrain> it is slightly faster then the former method :p 21:45:54 <TrueBrain> but the first request is very slow :p 21:48:24 *** LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has quit [Quit: When the chips are down, well, the buffalo is empty] 21:50:10 *** Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd 21:52:26 <peter1138> Well 21:52:31 <peter1138> I already had a checkout :p 21:52:50 <TrueBrain> I ment to the http :) 21:52:56 <peter1138> added 9513 changesets with 2455 changes to 1533 files (+1 heads) 21:52:57 <peter1138> :p 21:53:16 <TrueBrain> and yes, this version is a bit more .. .complete 21:53:24 <TrueBrain> with tnx to Rubidium for removing the .... 'branch' mistake ;) 21:53:28 <TrueBrain> lets state it just never happened :) 21:53:48 <peter1138> well, nini 21:54:50 <TrueBrain> night peter1138 22:01:11 *** clochette [~clochette@212-198-248-33.rev.numericable.fr] has joined #openttd 22:01:23 *** ecke [~ecke@21.161.broadband7.iol.cz] has quit [Quit: ecke] 22:03:16 *** clochette [~clochette@212-198-248-33.rev.numericable.fr] has quit [] 22:21:02 *** fonso [~fonso@brln-d9bacf2b.pool.mediaWays.net] has quit [Quit: Kopete 0.12.7 : http://kopete.kde.org] 22:24:01 *** curson [~curzon@79-68-37-51.dynamic.dsl.as9105.com] has quit [Quit: If everything seems to be going well, you have obviously overlooked something.] 22:26:26 <Ammler> TrueBrain: you should change your status, it is still retired :-) 22:27:43 <TrueBrain> I am still are, OpenTTD main development-wise 22:27:57 *** Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has joined #openttd 22:27:58 *** mode/#openttd [+o Bjarni] by ChanServ 22:28:04 <ln> Bjarni! 22:28:14 <Bjarni> hello 22:28:15 <TrueBrain> ln: you are happy to see him... why? 22:28:21 <Bjarni> finally home 22:28:30 <Bjarni> TrueBrain: I wondered about the same thing :/ 22:28:37 <TrueBrain> glad we agree on that :) 22:28:40 <TrueBrain> hi btw :) 22:29:00 <Bjarni> hi TrueBrain 22:29:39 <ln> TrueBrain: i could equally well be shocked to see him. 22:29:57 <TrueBrain> I was 22:29:58 <TrueBrain> :p 22:30:17 <ln> or just surprised. 22:30:25 <TrueBrain> no, shocked 22:30:26 <TrueBrain> clearly 22:34:05 *** DJNekkid_ [~chatzilla@static217-26.adsl.no] has joined #openttd 22:34:07 *** DJNekkid_ is now known as DJNekkid 22:34:13 <DJNekkid> hi all ... 22:34:17 <DJNekkid> are there any known bugs in the color window? 22:34:27 <TrueBrain> gimp works pretty well here 22:34:31 <DJNekkid> i mean ... the extended window, like monorail have it's own color and such 22:34:32 <TrueBrain> but I don't see what it has to do with OpenTTD :) 22:34:47 <DJNekkid> hehe! 22:35:54 <DJNekkid> well, i take it you didnt understand what i ment? 22:36:20 <TrueBrain> who would have guessed :) 22:36:22 <TrueBrain> 'the color window' 22:36:24 <Rubidium> seems to work as it should work 22:36:27 <TrueBrain> how vague can one be :) 22:37:19 <DJNekkid> even with newgrfs? 22:37:28 <Rubidium> yes 22:37:51 <DJNekkid> hmm 22:39:43 <welshdragon> what ports does openttd use? 22:40:02 <Prof_Frink> Dover 22:40:12 <Prof_Frink> Southampton 22:40:14 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Read error: Connection reset by peer] 22:40:15 <TrueBrain> @openttd ports 22:40:16 <DorpsGek> TrueBrain: OpenTTD uses TCP and UDP port 3979 for server <-> client communication and UDP port 3978 for masterserver (advertise) communication (outbound) 22:40:17 <welshdragon> shush you 22:40:30 <TrueBrain> lol @ Prof_Frink :) Genious :) 22:40:36 <Prof_Frink> I am. 22:41:01 <TrueBrain> and now it smells here 22:41:02 <TrueBrain> brr 22:41:09 <SmatZ> hehe 22:41:11 *** olgagirl [~olgagirl@212-198-248-33.rev.numericable.fr] has joined #openttd 22:41:17 <SmatZ> olga! girl! 22:41:36 *** Progman [~progman@p57A1D1E3.dip.t-dialin.net] has quit [Remote host closed the connection] 22:41:37 <TrueBrain> try PMing her :p 22:41:41 <TrueBrain> well, 'it' 22:41:47 <SmatZ> hehe 22:41:53 <TrueBrain> really, if it leaves again in 2 minutes 22:41:55 <TrueBrain> you want to :) 22:41:58 <DJNekkid> http://bildr.no/image/234062.jpeg 22:41:58 <dih> hello :-) 22:41:59 <welshdragon> actually, my bt homehub (no comments please) may have openttd saved as a preset 22:42:00 <dih> HEY 22:42:03 <DJNekkid> look at that one please 22:42:04 * dih smiles from one ear to another 22:42:14 <dih> nice to see you here TrueBrain 22:42:17 <SmatZ> hello olgagirl 22:42:19 <TrueBrain> dih: who? where? 22:42:21 <TrueBrain> SmatZ: in a PM! 22:42:38 *** olgagirl [~olgagirl@212-198-248-33.rev.numericable.fr] has quit [] 22:42:42 <SmatZ> :'-( 22:42:44 <SmatZ> too late 22:42:48 <Prof_Frink> SmatZ: Now look wat you did 22:42:54 <TrueBrain> SmatZ: on an other IRC network I am on, we klined those addresses 22:42:55 <SmatZ> sorry guys 22:42:58 <TrueBrain> they are 'scan' bots 22:43:02 <TrueBrain> REALLY annoying 22:43:07 <SmatZ> what do they want? 22:43:08 <TrueBrain> you can have up to 100 a day .. 22:43:33 <TrueBrain> I suspect http://www.gogloom.com/ 22:43:40 <Prof_Frink> Aye, they pop up on blitzed too 22:43:58 <SmatZ> TRUE CHAT 22:44:06 <TrueBrain> http://www.gogloom.com/OFTC/openttd/ 22:44:07 <SmatZ> looks... suspicious, TrueBrain :) 22:44:16 <TrueBrain> reason it is klined on most networks :) 22:44:18 <TrueBrain> really annoying 22:44:32 *** Lakie [~Lakie@80.247.163.109] has quit [Killed (NickServ (Too many failed password attempts.))] 22:44:32 *** Lakie [~Lakie@80.247.163.109] has joined #openttd 22:44:33 <DJNekkid> TrueBrain: well if you need elaboration check this picture ... http://bildr.no/image/234062.jpeg it seems like the monorails dont get appropiate color 22:44:45 <TrueBrain> DJNekkid: wrong person :) 22:44:58 <DJNekkid> oh :) 22:45:02 <SmatZ> hehe 22:45:22 <TrueBrain> anyway, SmatZ, if you send a PM to those bots 22:45:23 <TrueBrain> it is fun 22:45:27 <TrueBrain> they talk back for 2 or 3 lines 22:45:29 <TrueBrain> clearly automated 22:45:32 <TrueBrain> very amuzing :) 22:45:42 <Rubidium> DJNekkid: looks like the trains have no company colour capability 22:45:43 <SmatZ> :-) 22:45:51 <welshdragon> thank you re: ports... my game kept desynching 22:46:24 <DJNekkid> Rubidium: they are in magic blue and magic 2cc green 22:47:01 <Rubidium> then they're maybe dmus or emus 22:49:06 <DJNekkid> nope, not that either 22:49:37 <DJNekkid> well, a few are, but that is just for testing 22:50:58 <DJNekkid> that helped tho 22:51:06 <DJNekkid> but it didnt change on monorail trains 22:51:37 <DJNekkid> or ... perhaps i need 19 32 ... 22:51:38 <DJNekkid> sec 22:52:24 <DJNekkid> yea 22:52:27 <DJNekkid> that helped 22:55:30 <CIA-5> OpenTTD: glx * r13904 /trunk/src/strings.cpp: -Fix (r13715): 'cast from/to pointer to/from integer of different size' warnings 22:58:47 *** unenana [~unenana@212-198-248-33.rev.numericable.fr] has joined #openttd 23:00:54 *** unenana [~unenana@212-198-248-33.rev.numericable.fr] has quit [] 23:01:08 *** Zuu [~Zuu@c-fd4ee055.510-8-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving] 23:03:42 *** Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has quit [Quit: Leaving] 23:07:10 *** bleepy [bleepy@5ad34870.bb.sky.com] has quit [Ping timeout: 480 seconds] 23:13:44 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd 23:16:29 *** Dred_furst [~Dred_furs@user-514d7e3a.l2.c2.dsl.pol.co.uk] has quit [Read error: Connection reset by peer] 23:18:49 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Quit: leaving] 23:19:01 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd 23:25:11 * TrueBrain wondws why nobody notice it that bugs.openttd.org isn't working :p 23:25:16 <TrueBrain> do none of you look at that or something? 23:27:53 <dih> http://nightly.openttd.org/devs/rev <- is there also a file that shows the current stable release? 23:28:19 <TrueBrain> there are more of such files 23:28:21 <TrueBrain> not sure where and how they are called 23:28:36 <dih> that would be exactly the info i was after :-P 23:28:47 <TrueBrain> most likely 23:28:48 <TrueBrain> :) 23:28:53 <SmatZ> $TOPIC[1] 23:29:16 <dih> ? 23:34:33 <Eddi|zuHause2> svn ls tags | sort | tail -n 1 23:36:00 <TrueBrain> Eddi|zuHause2: not the latest stable ;0 23:36:08 <TrueBrain> svn ls tags | sort | grep -v RC | tail -n 1 23:36:11 <TrueBrain> might work better 23:36:17 <Eddi|zuHause2> yeah, it might catch release candidates ;) 23:36:39 <SmatZ> | grep -v beta | 23:36:52 <TrueBrain> grep -v "RC\|beta" 23:36:53 <TrueBrain> ;) 23:36:56 <SmatZ> :) 23:38:22 <Eddi|zuHause2> next thing would be some magic with the rss-feed ;) 23:38:32 <Ammler> or grep the readme in trunk 23:38:39 <TrueBrain> unwise :p 23:38:47 <Eddi|zuHause2> bad idea :p 23:38:51 <Ammler> :P 23:39:57 <Eddi|zuHause2> chances are that a) the readme has not been touched since 0.6 branch or b) it is updated for 0.7 already 23:40:32 <Ammler> it might still be a beta there :-) 23:41:04 *** GoneWacko [GoneWacko@86-60-147-155-dyn-dsl.ssp.fi] has quit [] 23:42:54 *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Quit: Leaving.] 23:59:47 *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Ping timeout: 480 seconds]